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ABSTRACT 


This  thesis  analyzes  the  current  management  information  systems  in  place  at  Silas 
B.  Hays  Army  Community  Hospital  with  in  depth  research  into  the  hospital’s  largest 
department,  the  Department  of  Family  Practice  and  Community  Medicine.  The  findings 
of  the  research  indicate  these  systems  are  not  meeting  the  needs  of  department 
managers  within  the  hospital.  This  thesis  contains  a  requirements  analysis  for  an 
improved  information  system  for  the  department.  The  process  of  identifying  the 
targeted  users,  selecting  the  appropriate  development  methodology,  and  identifying  the 
user’s  information  requirements  is  discussed.  The  value  of  the  information  required  by 
the  department  manager,  both  in  content  and  format,  is  examined.  The  requirements 
analysis  is  based  on  a  combination  of  systems  development  life  cycle  and  prototypiiig 
methodologies  for  information  systems  development  and  can  be  used  to  design, 
construct,  and  implement  an  information  system  for  the  targeted  department.  The 
requirements  analysis  can  also  be  used  to  study  the  expandability  of  the  proprosed 
information  system  to  departments  throughout  Silas  B.  Hays  Army  Community 
Hospital. 
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I.  INTRODUCTION 


A.  BACKGROUND 

Silas  B.  Hays  Army  Community  Hospital  (SBHACH)  is  a  large,  full  service 
medical  department  activity  (MEDDAC)  providing  health  care  to  active  duty,  retired, 
and  dependent  personnel  living  in  and  around  Fort  Ord.  The  MEDDAC  also  provides 
regional  medical  services  to  persormel  from  Hunter  Liggett  Military  Reservation, 
Presidio  of  Monterey,  Sacramento  Army  Dep>ot,  United  States  Naval  Postgraduate 
School,  and  the  Sharpe  Army  Depot.  SBHACH’s  annual  operating  budget  is  over  seven 
million  doUars  and  in  fiscal  year  1988,  over  460,000  patients  were  treated.  The 
hospital  consists  of  13  major  medical  departments  which  provide  inpatient  and 
outpatient  service,  major  surgical  services,  military  medical  support,  and  veterinary 
service.  In  addition,  SBHACH  is  a  teaching  hospital  for  Army  doctors  and  provides 
occupational  health  to  civilian  employees.  The  goal  of  SBHACH  is  to  provide  its 
patients  with  the  best  medical  care  jrossible. 

The  quality  of  the  medical  care  provided  depends  on  factors  such  as  the  quality 
of  the  hospital  personnel  and  the  effective  use  of  available  resources,  e.g.  personnel, 
money,  time,  and  medical  supplies.  Another  factor,  the  efficient  use  of  resources, 
indirectly  affects  the  quality  of  care  provided  because  this  factor  will  determine  the 
continued  availability  of  the  resources.  One  of  the  biggest  obstacles  SBHACH  faces 
in  trying  to  reach  its  goal  is  the  limited  resources  with  which  it  must  operate. 
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SBHACH  doctors  and  administrators  must  constantly  deal  with  resource 
constraints.  They  are  continually  searching  for  more  efficient  and  effective  resource 
management  to  deal  with  these  constraints  while,  at  the  same  time,  improving  the 
quality  of  care  provided  to  the  patients.  In  searching  for  the  balance  between  cost 
efficiency  and  quality  of  care,  hospital  administrators  are  turning  to  information 
systems,  both  automated  and  manual,  in  the  belief  that  better  information  will  help 
them  operate  more  cost  effectively. 

B.  PURPOSE 

The  purpose  of  this  thesis  is  to  study  the  current  management  information  systems 
in  place  at  Silas  L».  Hays  Army  Community  Hospital  and  determine  if  these  systems 
are  meeting  the  needs  of  department  managers  within  the  hospital.  In  identifying  the 
requirements  of  key  department  decision  makers,  we  wUl  propose  improvements  to  the 
information  system  where  the  current  system  fails  to  meet  the  department  manager’s 
needs.  Ultimately,  the  thesis  will  provide  a  design  for  an  information  system  which  will 
meet  the  needs  of  department  decision  makers  more  effectively  and  efficiently  than 
current  systems. 

C.  SCOPE 

Due  to  time  limitations,  the  research  did  not  encompass  the  entire  hospital 
operation.  Therefore,  after  initial  interviews  and  some  detailed  study,  one  department 
was  selected  based  on  its  high  volume  and  overall  impact  on  the  hospital.  The 
department  chosen  for  the  research  was  the  Department  of  Family  Practice  and 
Community  Medicine  (DFPCM).  The  DFPCM  is  one  of  the  13  major  departments 
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within  SBHACH  and  serves  nearly  53  percent  of  the  hospital’s  patients.  An  additional 
motivation  for  limiting  the  scope  of  the  research  was  the  increased  depth  of  the 
analysis  and  design  of  an  information  system  that  would  otherwise  be  possible. 

In  addition  to  the  direct  study  of  the  DFPCM,  it  was  necessary  to  conduct 
research  in  the  many  supporting  units  which  influence  the  department’s  overall  ability 
to  function.  The  following  support  divisions  were  contacted  during  the  course  of 
research: 

•  Resource  Management  Division 

•  Information  Management  Division 

•  Clinical  Support  Division 

•  Department  of  Nursing 

•  Logistics  Division 

•  Personnel  Division 

•  Patient  Administration  Division 

D.  METHODS  AND  ORGANIZATION 

The  thesis  research  followed  the  information  systems  development  life  cycle 
described  in  the  first  two  sections  of  Chapter  11.  Chapter  n  discusses  the  theory  of 
information  systems  and  the  analysis  and  design  of  such  systems.  The  last  section  of 
Chapter  II  introduces  the  application  of  information  systems  to  health  care.  Research 
was  conducted  to  discover  the  history,  current  status,  and  fiiture  of  hospital  information 
systems  (HISs)  and  the  critical  nature  of  these  specialized  systems. 

The  DFPCM  organization  and  functions  are  described  in  detail  in  the  first  section 
of  Chapter  HI.  Section  2  of  Chapter  ID  discusses  the  results  of  the  current  systems 
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analysis.  Data  Flow  Diagrams  (DFDs)  are  introduced  in  Chapter  IE.  DFDs 
diagrammatically  portray  the  current  information  systems  within  the  DFPCM. 

Chapter  IV  covers  the  requirements  for  improving  the  existing  information 
systems  within  the  DFPCM  and  how  these  improvements  can  be  accomplished  using 
an  automated  information  management  system.  The  findings  in  Chapter  IV  are  a  direct 
result  of  the  analysis  conducted  in  Chapter  HI  and  described  what  is  necessary  for  the 
information  system  to  meet  the  needs  of  the  department  managers. 

The  detailed  systems  requirements  analysis  is  presented  in  Chapter  V, 
incorporating  the  functional  requirements  and  alternatives  selected  in  the  previous 
chapters.  User  Concept  Diagrams  (UCDs)  are  introduced  in  Chapter  V  to 
diagrammatically  portray  the  proposed  information  systems  for  the  DFPCM.  The 
requirements  analysis,  as  described  in  the  chapter,  is  for  the  DFPCM  alone.  This 
analysis  can  be  used  to  design  and  implement  a  management  information  system  for 
this  department,  or  with  additional  study,  may  be  expandable  to  other  clinics  within  the 
hospital. 

Conclusions  and  recommendations  resulting  from  this  thesis  are  given  in  Chapter 
VI.  Chapter  VI  also  suggests  directions  for  further  research  work. 
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II.  INFORMATION  SYSTEMS 


A.  INTRODUCTION 

This  chapter  introduces  the  concepts  of  an  information  system  and  the  systems 
development  process  and  discusses  the  impact  of  information  systems  within  a  hospital 
environment. 

Section  B,  System  Design  Concepts,  describes  the  information  systems 
development  methodologies  used  in  the  thesis  to  design  the  information  system  for  the 
Department  of  Family  Practice  and  Community  Medicine.  The  process  of  selecting  the 
most  r^ropriate  system  development  methodology(ies)  is  also  examined. 

Section  C,  Hospital  Information  Systems  (HISs),  describes  the  critical  nature  of 
the  hospital  organization  and  it’s  impact  on  the  role  of  information  systems  within  the 
hospital  envirorunent,  both  historically  and  in  the  near  future.  Also  presented  in 
Section  C  is  a  description  of  the  information  systems  currently  used  at  SBHACH. 

B.  SYSTEM’S  DESIGN  CONCEPTS 

An  information  system  has  been  described  as  a  collection  of  human, 
computerized,  and  mechanical  agents  that  work  together  to  acquire,  produce,  handle, 
store,  use,  and  disseminate  information  (Lockeman,  1986,  p.  617).  Information  systems 
are  meant  to  support  the  day  to  day  operations,  management,  and  decision  making 
needs  of  an  organization.  An  effective  information  system  does  not  necessarily  have 
to  be  automated.  Information  systems  exist,  with  or  without  automation,  because 
workers  within  the  organization  require  some  sort  of  a  system  to  collect,  process,  and 
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exchange  the  information  they  need.  When  automation  is  deemed  necessary  and 
properly  designed,  it  can  provide  the  organization  with  an  increase  in  both  the 
efficiency  and  effectiveness  of  operations.  (Whitten,  Bendy,  and  Ho,  1986,  p.  40) 
There  are  four  important  considerations  in  the  development  of  an  effective 
information  system.  First  and  foremost,  the  system  must  be  designed  to  serve  the 
needs  of  the  users.  The  analyst  has  a  responsibility  to  provide  the  user  with  a  product 
that  is  both  useful  and  correct.  Secondly,  the  analyst  should  understand  the 
organization's  mission  to  build  the  system  to  effectively  su|^rt  that  mission.  Thirdly, 
information  systems  provide  one  or  more  of  the  three  information  functions  depicted 
in  Table  I.  The  analyst  must  determine  which  of  these  functions  the  system  should 
support  and  how  the  information  system  will  fit  within  the  organization  to  fulfill  those 
functions.  Lastly,  the  system’s  components,  as  depicted  in  Figure  1,  should  be 
designed  to  harmoniously  work  together  to  support  the  system’s  intended  purpose 
within  the  organization.  (Whitten,  Bendy,  and  Ho,  1986,  p.  692)  This  requires  the 
analyst  to  systematically  analyze  the  data  inputs,  data  flows,  processes,  and  information 
outputs.  (Kendall  and  Kendall,  1988,  p.  6) 

Table  I.  INFORMATION  FUNCTIONS 

Data  Processing  Systems 

Processes  large  amounts  of  data  for  routine  organization 

transactions. 

Management  Information  Systems 

Provides  periodic  reports  for  planning,  control  and  decision  making. 

Decision  Support  Systems 

Supports  decision  makers  by  providing  information  on  demand. 


IscQnii 

Coacroi 

Cocnpoflcoci 


•  Computer  equipment  or  Hardware.  Information  systems  may  Inciude  a  variety  of  hardware 
components,  induding  copiers,  caiculators,  and  computer  systems. 

•  Computer  Programs  or  Software.  A  system  is  a  mixture  of  programs  that  either  control  the 
computer  or  provide  applications  to  the  users. 

•  Users  (Knowledge  workers)  are  the  most  vital  part  of  the  Information  system's  components. 

They  are  the  central  theme  in  any  design  methodology. 

•  Methods  and  Procedures.  Methods  refer  to  how  the  system  works  whereas  procedures 
describe  how  to  perform  the  job  and  how  to  make  decisions. 

•  Data  Storage.  This  Is  a  fundamental  component  of  the  system.  This  Is  the  raw  data  that  must 
be  accessed  to  process  into  useful  information. 

•  Internal  Controls.  Feedback  and  control  are  system  concepts  that  must  be  added  to  any 
system  to  ensure  its  proper  operation. 

Figure  1.  Information  System  Components  (Whitten,  Bently,  and  Ho,  1986,  p.  692) 
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Prior  to  attempting  die  design  of  an  information  system,  the  systems  analyst 
must  choose  a  design  methodology  which  will  best  meet  his  or  her  needs  and  the 
user’s  needs.  This  selection  process  and  a  description  of  die  methodology  used  in  this 
thesis  is  described  in  the  following  sections. 

1.  Systems  Development  Life  Cycle  Methodology 

System  development  in  the  late  1960s'  was  often  behind  schedule,  over 
budget,  expensive,  and  poorly  suited  to  the  users’  requirements.  As  a  result,  the  early 
system  designers  developed  a  set  of  stmctured  methodologies  to  make  the  development 
process  more  orderly  and  manageable.  The  emergence  of  structured  methodologies 
provided  the  analyst  with  a  welcome  escape  from  the  haphazard  approaches  used  to 
develop  the  requirements,  specifications,  and  programs  used  in  the  early  design  models 
(Ceri,  1982,  p.  208). 

As  the  structured  s^roaches  became  accepted  as  a  viable  systems  design 
alternative,  more  analysts  began  to  perceive  that  the  structured  methodology  could  even 
be  further  improved  with  the  inclusion  of  a  life  cycle  within  the  model.  This  enhanced 
structured  {q)proach,  dubbed  the  Systems  Development  Life  Cycle,  was  used  by  these 
analysts  to  bring  together  all  of  the  already  proven  systems  design  techniques  with  the 
successful  project  management  techniques.  This  system  development  life  cycle 
methodology  emerged  as  the  most  preferred  method  of  all  of  the  system  design 
methodologies.  (Wassetmann,  1984,  p.  44) 


'  This  contiiiiies  to  be  the  case  in  the  eighties. 
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Figure  2  portrays  the  Systems  Development  Life  Cycle  methodology.  This 
qyproach  provided  several  significant  advantages  over  the  non-structured  qjproaches  and 
the  early  forms  of  the  structured  methodologies.  This  design  r^roach  gave  the  systems 
analyst  a  better  understanding  of  the  user’s  requirements  while  the  increasing  the  user’s 
comprehension  and  participation  in  the  design  process.  (Willis,  Huston,  and  d’Ouville, 
1988,  p.  56)  Users  also  tended  to  be  a  lot  more  satisfied  with  the  final  outcome  of  a 
system  designed  using  this  methodology.  Information  systems  designed  using  this 
methodology  were  also  found  to  be  more  flexible  and  maintainable  then  the  early 
approaches.  (Sumner  and  Sitek,  1986,  p.  235) 

As  Figure  2  shows,  the  life  cycle  begins  with  a  project  development  request. 
Before  a  more  detailed  systems  study  is  started,  the  systems  analyst  surveys  the 
problem,  opportunity,  or  directive  that  initiated  the  request.  This  survey  is  used  to 
determine  whether  oi  not  significant  resources  should  be  committed  to  the  project.  If 
the  system  development  is  approved,  the  development  enters  the  first  major  phase  of 
the  SDLC,  the  study  phase.  The  goal  of  the  study  phase  is  to  educate  the  analyst  about 
the  current  system,  thus  allowing  the  causes  and  effects  of  the  problems  to  be 
discovered.  This  type  of  analysis  is  presented  in  Chapter  m  of  this  thesis. 

The  next  phase,  the  requirements  phase,  is  the  most  critical  of  the  life  cycle 
phases  because  it  provides  the  foundation  for  all  subsequent  phases  (Willis,  Huston,  and 
d’Ouville,  1988,  p.  56).  This  phase  is  concerned  with  the  analyst  understanding  the 
problems  found  in  the  study  phase  and  describing  them  in  terms  of  the  activities,  data, 
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information  flows,  relationships,  and  system  constraints  necessary  to  solve  the  problem 
(Ceri,  1982,  p.  205).  This  type  of  analysis  is  presented  in  Chapters  IV  and  V  of  this 
thesis. 


Figure  2.  Systems  Development  Life  Cycle. 
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The  evaluation  phase  looks  at  how  the  new  system  should  be  developed.  The 
analyst  must  seek  out  all  possible  solutions  to  the  problem  and  generate  a  set  of 
alternative  proposals  to  solve  the  problem.  Each  alternative  is  then  evaluated  on 
technical,  operational,  and  economic  feasibility.  The  outcome  of  this  phase  should  be 
a  technically  feasible  solution.  (Whitten,  Bently,  and  Ho,  1986,  p.  149) 

If  this  solution  calls  for  new  hardware  or  software,  the  selection  phase 
becomes  necessary.  During  the  selection  phase,  the  analyst  determines  which  system 
specifications  are  important  for  the  equipment  or  software  required  for  the  new  system. 
Proposals  are  then  developed  and  sent  to  vendors.  Once  the  vendors’  proposals  are 
returned,  the  systems  analyst  selects  the  hardware  and  software  configurations  that  best 
meets  the  project’s  needs  at  the  most  reasonable  cost.  (Whitten,  Bently,  and  Ho,  1986, 
p.  151) 

Given  the  user  requirements,  a  feasible  solution,  and  the  hardware  or 
software  configurations  from  the  selection  phase,  the  analyst  can  now  design  and 
construct  the  information  system.  Computer  outputs  are  normally  designed  first, 
followed  by  files/databases,  and  subsequently  the  user  inputs  and  terminal  dialogues. 
The  design  phase  is  where  system  controls,  as  implemented  in  methods  and  procedures, 
first  enter  the  developmental  life  cycle.  The  deliverable  of  this  phase  is  the  completed 
design  specification  and  the  preliminary  procedures  necessary  for  the  construction  of 
the  new  system.  The  construction  and  design  phases  are  fiequendy  the  most  time 
consuming  and  tedious  phases,  particularly  if  the  requirements  are  incomplete  or  do  not 
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reflect  the  actual  user’s  requirements.  Finally  the  system  is  delivered,  the  users  are 
trained,  and  the  system  enters  the  maintenance  phase.  (Whitten,  Bently,  and  Ho,  1986, 
pp.  151-155) 


Throughout  the  various  phases,  the  analyst  is  collecting  facts,  documenting 
the  system,  presenting  ideas,  and  reevaluating  the  feasibility  of  the  system.  All  of  the 
phases  of  the  system  development  life  cycle  are  not  discreet  and  distinct  phases.  Figure 
3  illustrates  how  each  phase  can  overlap  within  the  life  cycle.  (Whitten,  Bently,  and 
Ho,  1986,  p.  157)  As  a  life  cycle  model  should  indicate,  the  process  will  begin  again 
as  new  project  requests  are  generated,  the  organization  evolves,  or  the  system  once 
again  fails  to  meet  the  user’s  requirements. 

Activity 
Survey  the  Situation 

Study  the  Current  System 

Define  User  Requirements 

Evaluate  Alternative  Solutions 
Select  New  Computer 
Equipment  and  Software 

Design  the  New  System 

Construct  the  New  System 

Deliver  the  New  System 


Figure  3.  Overlap  Opportunities  within  the  Systems  Development  Life  Cycle.  (Wliitten, 
Bently,  and  Ho,  1986,  p.  157) 

In  spite  of  the  large  number  of  structured  methodologies  available,  this  type 
of  systems  analysis  is  not  widely  used  (Sumner  and  Sitek,  1986,  p.  235).  Today,  only 
about  ten  percent  of  the  data  processing  organizations  in  North  America  practice 
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structured  techniques  in  a  disciplined  fa^on  even  though  90%  of  the  community  is 
at  least  superficially  familiar  with  the  basic  concepts  (Yourdon,  1986,  p.  133). 

Prior  to  selecting  the  use  of  one  of  these  methodologies  in  our  thesis,  a 
closer  look  was  taken  to  deteimine  why  these  methodologies,  so  often  taught  at 
universities,  were  not  being  used.  Yourdon  explains  that  there  are  many  reasons  for  this 
reversal  in  the  attitudes  toward  structured  analysis.  He  felt  diat  the  primary  reason  for 
this  reversal  was  the  frustration  of  analysts  over  the  amount  of  manual  labor  required 
to  develop  systems  using  the  structured  methodologies.  Analysts  in  a  real  business 
environment  did  not  have  the  time  to  do  the  time  consuming  requirements 
documentation  necessary  for  the  requirements  analysis  when  there  was  a  large  backlog 
of  projects  awaiting  development.  The  analysts  also  became  increasingly  frustrated 
with  the  inability  to  apply  these  methodologies  to  complex,  real-time  systems. 
(Yourdon,  1986,  p.  133)  Additionally,  many  systems  analysts  were  not  trained  in  the 
use  of  the  methodologies  and  tools  and  were  unsure  as  to  which  tools  could  be 
effectively  used  within  the  phases  of  the  life  cycle  (Ceri,  1982,  p.  208).  One  of  the 
major  reasons  for  this  reversal  of  attitudes  was  the  development  of  the  prototyping 
methodologies  discussed  in  the  following  section.  Many  analysts  were  lured  away 
from  the  structured  approaches  to  systems  development  by  the  promise  that  prototyping 
could  be  used  to  interactively  design  and  progressively  tune  the  systems  design  without 
the  rigorous  requirements  of  the  stmctured  approaches  (Ceri,  1982,  p.  208). 

Too  often,  even  though  the  structured  techniques  were  used,  the  end  result 
was  a  better  design  that  still  did  not  meet  the  users’  needs.  Because  of  the  time  lag 
between  the  analysis  and  implementation  phases  in  the  structured  methodology,  the 
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users’  environment  changed  even  after  the  system’s  requirements  were  set  in  the 
requirements  and  design  phases.  The  users  also  had  difficulty  communicating  their 
requirements  to  the  analyst.  Senn  points  out  "users  can  point  to  features  they  like  or 
dislike  in  an  existing  system  more  easily  than  they  can  describe  them  in  an  imaginary 
or  proposed  system."  (Senn,  1987,  p.  611)  These  observations  led  to  the  conclusion 
that  a  better  design  methodology  was  needed  to  meet  system  development  requirements. 

2.  Prototyping  Methodologies 

Information  systems  analysts  saw  the  need  for  an  improved  design  method. 
They  felt  that  any  systems  development  £^proach  required  the  concurrent  learning  of 
both  the  analyst  and  the  users.  During  the  requirements  phase,  the  major  functions  of 
the  analyst  are  to  help  users  formalize  their  tasks  and  decision  processes,  ensure  that 
the  users  learn  the  analyst’s  modeling  techniques,  and  help  the  users  understand  the 
scope  of  the  project  (Cerveny,  1987,  p.98).  The  stmctured  methodologies  simply  did 
not  fulftll  this  requirement.  Recent  developments  in  computer  technology,  primarily  the 
introduction  of  user  friendly  code  generators,  allowed  the  systems  analysts  to  develop 
a  better  approach  to  the  systems  development  process.  This  new  approach,  prototyping, 
was  designed  to  alleviate  some  of  the  problems  that  concerned  the  systems  analysts 
about  the  traditional  approaches.  (Willis,  Huston,  and  d’Ouville,  1988,  p.  57) 

The  concept  of  prototyping  is  not  new.  In  engineering,  prototyping  has  long 
been  a  standard  for  developing  and  testing  new  products  and  systems  (Scharer,  1983, 
p.  60).  Prototyping  was  not  designed  to  replace  the  systems  development  life  cycle. 
Instead,  prototyping  enhances  the  life  cycle  by  promoting  the  mutual  learning  processes 
between  the  analyst  and  user  (Cerveny.  1987,  p.  98,  103).  Prototyping  uses  the  power 
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of  demonstration  to  enable  the  user  and  the  analyst  to  literally  see  their  specification 
in  action  (Scharer,  1983,  p.  60).  Prototyping  has  the  following  significant  advantages 
over  the  traditional  structured  methodologies: 

•  Gets  the  user  more  aaively  involved  in  design  and  development. 

•  Provides  the  user  with  a  tangible  means  of  comprehending  and  evaluating  the 
proposed  system. 

•  Achieves  more  meaningful  user  feedback  in  temis  of  their  needs  and 
requirements. 

•  Develops  better  relationships  between  systems  analysts  and  user  groups. 

•  Results  in  fewer  post  implementation  changes,  resulting  in  lower  maintenance 
costs.  (Kroenke,  1987,  p.  157) 

•  The  system  that  had  been  prototyped  could  be  developed  in  one  quarter  of  the 
time  required  of  the  structured  methodologies.  (Willis,  Huston,  and  d’Ouville, 
1988,  p.  58)  (Harrison,  1985) 

The  main  benefit  of  using  a  prototype  methodology  is  the  development  of 
an  information  system  that  more  closely  fits  the  needs  of  the  organization.  Prototyping 
also  reduces  the  risks  involved  with  the  development  cycle  by  getting  the  system  into 
operation  quickly  and  keeping  the  system  simple.  (Cerveny,  1987,  p.57)  Prototyping 
is  not  superior  to  the  traditional  methods  in  all  cases.  Table  n  depicts  the  factors  that 
favor  either  the  traditional  or  prototype  methodologies. 

Figure  4  depicts  the  modified  systems  development  life  cycle  where 
prototyping  techniques  have  been  integrated  into  the  life  cycle.  After  the  users  have 
specified  their  needs,  the  analyst  can  then  demonstrate  how  the  proposed  system  can 
meet  those  needs.  Design  by  prototyping  consolidates  the  requirements  definition, 
design,  and  construction  stages  of  the  typical  system  development  life  cycle  discussed 
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earlier.  These  three  activities  take  up  approximately  60  percent  of  the  manhours 
required  for  a  system  study.  Consequendy,  prototyping  yields  a  net  saving  in  effort 
when  it  is  utilized  in  the  design  of  information  systems.  (Willis,  Huston,  and  d’Ouville, 
1988,  p.  58) 

Table  U.  FACTORS  FAVORING  ALTERNATIVE  DEVELOPMENT  METHODS 
(Willis,  Huston,  and  d’Ouville,  1988,  p.  58) 

Project  Characteristics  of  Alternative  Development  Methods 

Factors  Favoring  Traditional  Systems  Development 

•  Data  needs  are  clearly  defined. 

•  Systems  have  long  life  expectancy. 

•  Tight  controls  are  required. 

•  Development  risks  are  clearly  defined. 

•  Essential  system  features  are  known  in  advance. 

•  Operational  characteristics  are  well  understood. 

Factors  Favoring  Prototyping 

•  User  requirements  are  uncertain. 

•  Procedure  changes  are  extensive. 

•  User  environment  is  volatile. 

•  System  has  relatively  short  life  expectancy. 

•  System  needs  to  be  operational  in  short  period  of  time. 

•  Changes  in  specifications  are  anticipated. 

The  construction  of  a  prototype  model  requires  that  the  systems  analyst 

follow  the  six  basic  steps  listed  in  Table  m  and  described  below. 

Table  III.  STEPS  IN  PROTOTYPE  DEVELOPMENT  (Willis,  Huston,  and  d’Ouville, 
1988,  p.  57) 

Prototyping  Design  Steps 

1.  Select  an  appropriate  application. 

2.  Identify  basic  needs. 

3.  Develop  the  working  model. 

4.  Refine  the  model  and  system  interface  characteristics. 

5.  Implement  revisions  and  enhancements. 

6.  Prepare  prototype  documentation  and  plan  for  development. 
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Figure  4.  Prototyping  Systems  Development  Life  Cycle 
a.  Step  One:  Select  Appropriate  Application 

The  first  consideration  for  the  systems  analyst  is  to  determine  if  the 
system  under  development  favors  the  prototyping  design  methodology.  This 
methodology  is  not  superior  to  the  structured  approaches  in  all  cases.  The  analyst  takes 
into  consideration  all  the  factors  listed  in  Table  11,  Factors  Favoring  Alternative 
Development  Methods,  the  user’s  environment,  and  the  availability  of  prototyping  tools 
to  determine  if  the  system  can  best  be  developed  with  the  prototyping  approach. 
(Willis,  Huston,  and  d’Ouville,  1988,  p.  58) 
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The  environment  within  the  DFPCM  favored  the  use  of  prototyping  for 


the  following  reasons: 

•  Uncertain  user  requirements. 

•  The  environment  was  particularly  unstable,  subject  to  wide  swings  of  personnel 
availability  and  woik  procedures. 

•  The  new  system  is  needed  immediately  to  meet  the  department’s  expanding 
role  within  the  hospital. 

•  The  system  was  expected  to  have  a  relatively  short  life  cycle. 

•  Numerous  changes  were  expected  in  the  specifications,  as  reports,  procedures, 
and  requirements  for  information  tqrpeared  to  be  changing  daily. 

b.  Step  Two:  Identify  Basic  Needs 
The  second  step  in  prototyping  involves  getting  a  better  understanding 

of  the  problem  or  opportunity  that  was  developed  in  the  study  phase.  (Willis,  Huston, 

i 

I 

and  d’Ouville,  1988,  p.  59)  The  goal  of  this  step  is  to  develop  enough  of  an 
understanding  of  the  problem  to  enable  the  design  and  construction  of  the  initial 
prototype  model  (Boar,  1984,  p.  67). 

c.  Step  Three:  Develop  MVorHng  Model 

The  purpose  of  this  step  is  to  build  the  initial  version  of  the  prototype. 
Screens  and  dociunents  layout  are  defined,  data  records  are  specified,  and  other  model 

i 

characteristics  are  established  (Willis,  Huston,  and  d’Ouville,  1988,  p.  59).  Content, 
not  presentation,  should  be  the  primary  goal  of  this  initial  model  (Boar,  1984,  p.  69) 
The  analyst’s  intent,  in  this  stage,  is  not  to  come  up  with  the  perfect  model  but  to 
^  develop  a  model  that  best  matches  the  user’s  view  of  the  problem.  (Quality  is  critical. 

If  the  model  is  incon^lete,  it  results  in  a  poor  foundation  for  the  rest  of  the 


i 

i 
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development  cycle.  The  target  time  for  delivery  of  the  initial  model,  depending  on  the 
prototype  environment,  should  be  three  to  six  weeks.  (Boar,  1984,  p.  69) 

d.  Step  Four:  Refine  Model  and  System  Interface  Characteristics 

In  this  step,  the  system  is  refined  so  that  each  of  the  initial  prototypes 
tested  earlier  are  now  required  to  woik  togedier.  The  analyst’s  goal  in  this  stq)  is  to 
immediately  test  new  ideas  to  see  what  refinements  will  satisfy  die  majority  of  the 
users.  As  users  review  this  refined  prototype  and  changes  are  made,  the  important 
changes  are  documented  for  later  reference.  (Willis,  Huston,  and  d’Ouville,  1988,  p.  S9) 

e.  Step  Five:  Implement  Revisions  and  Enhancements 

The  objective  of  this  step  is  to  allow  the  users  to  review  the 
information  system  in  as  complete  a  context  as  possible.  This  review  occurs  after  all 
the  changes  and  enhancements  have  been  implemented  and  serves  as  the  final 
evaluation  of  the  information  system  in  the  eyes  of  the  user.  (Willis,  Huston,  and 
d’Ouville,  1988,  p.  59)  Except  for  minor  problems,  the  prototype  is  essentially 
complete. 

/.  Step  Six:  Prepare  Prototype  Documentation  and  Plan  for 
Development 

This  stage  of  the  prototype  cycle  involves  the  completion  of  the 
documentation  for  the  system  and  the  determination  of  the  fate  of  the  prototype.  The 
format  and  the  extent  of  the  documentation  rests  largely  with  the  project  manager.  The 
final  decision  is  made  concerning  how  the  prototype  should  be  used  in  the  new  system. 
At  this  stage  the  analyst  can  go  in  three  directions  with  the  prototype. 
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•  If  the  implementation  of  this  prototype  is  too  expensive  or  infeasible,  the 
system  can  be  abandoned. 

•  Depending  on  the  analyst’s  prototyping  development  tools,  the  prototype  could 
actually  be  implemented  directly. 

•  As  is  the  case  with  this  thesis,  the  prototype  could  be  used  simply  as  a  step 
to  another  stage  of  the  development  process.  The  prototype  provides  the 
analyst  with  a  knowledge  base  for  the  design  of  the  new  system.  (Willis, 
Huston,  and  d’Ouville,  1988,  p.  59) 

The  successful  prototype  clearly  enhances  the  traditional  {^roaches.  It 
is  usually  considerably  cheaper,  less  risky,  and  conveniently  keeps  the  system  simple 
from  the  user’s  perspective.  It’s  primary  advantage  is  that  it  allows  the  user  to  see  the 
application  in  its  operational  context  and  determine  if  the  current  design  fits  his  or  her 
needs.  (Willis,  Huston,  and  d’Ouville,  1988,  p.60) 

C.  HOSPITAL  INFORMATION  SYSTEMS  (HIS) 

L  The  Critical  Nature  of  Hospital  Information  Systems 

The  health  care  delivery  system  in  a  hospital  environment  is  generally 
viewed  as  an  industry.  This  industry  has  seen  major  changes  in  recent  decades  due  to 
breakthroughs  in  medicine  and  technology.  The  cost  of  health  care  nationwide  has 
increased  more  than  tenfold  since  1950  to  over  $120  billion  making  health  care  one 
of  this  nation’s  largest  industries  (Rakich  and  Darr,  1978,  p.  1).  In  addition  to  the 
major  changes  taking  place  in  the  health  care  industry,  the  very  nature  of  health  care 
delivery  creates  a  complex  organization  for  the  hospital  administrator.  Rakich  and  Darr 
suggest  the  hospital  is  one  of  the  most  complex  organizations  in  existence  based  on  the 
characteristics  discussed  below. 
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•  There  is  a  wide  diversity  of  objectives  and  goals  for  different  personnel  and 
subsystems  (e.g.,  patient  care,  education,  research,  accommodations, 
administration). 

•  The  diversity  of  persoimel  ranges  from  highly  skilled  physicians  and 
administrators  to  unskilled  laborers. 

•  The  ho^ital  is  in  continual  operation. 

•  Hospitals  deal  with  life  and  death  decisions. 

•  Measuring  the  major  product  (patient  care)  is  difficult.  (Rakich  and  Darr,  1978, 

p.  1) 

These  often  conflicting  attributes  can  cause  problems  for  hospital  decision 
makers.  A  dichotomy  is  created  by  the  conflicting  goals  of  the  hospital’s  two 
components,  management  and  operations,  and  becomes  most  evident  and  in^rtant  in 
an  environment  where  societal  pressures  and  legal  implications  concerning  ethical 
behavior  are  greatest.  The  non-medical  management  component  (sometimes  referred  to 
as  "bean  counters")  measures  efficiency,  i.e.,  the  maximum  amount  of  output  (hospital 
services)  for  a  given  input  (cost).  The  medical  component  (health  care  providers) 
measures  performance  by  the  quality  of  care  provided  to  the  patient  (Longest,  1978, 
p.  125).  This  difference  of  purpose  and  objective  will  impact  the  manner  in  which 
information  is  managed  and  used  in  the  hospital  environment.  Figure  5  is  a  humorous 
portrayal  of  the  conflicts  which  exist  between  doctors  and  administrators  when 
considering  the  use  of  computer  resources  (Cowey  and  McAlister,  1980,  p.  141). 
However,  the  consequences  of  such  conflicts  are  quite  serious  and  play  an  important 
role  in  the  potential  effectiveness  of  a  hospital  information  system  (HIS). 

Another  factor  influencing  the  HIS  is  the  complexity  of  the  relationship 
between  the  doctor  and  the  patient.  The  ethics  and  responsibilities  involved  make 
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doctors  wary  of  new  technologies  and  methods  unless  the  benefits  to  the  patients  can 
be  proven.  (Safir,  1978,  p.  98) 


Figure  5.  Conflicts 

The  complexity  and  significance  of  health  care  organizations  described  in  the 
preceding  paragraphs  creates  a  critical  environment  for  a  HIS.  The  conflicts  which  exist 
have  affected  the  use  and  advancement  of  HISs  throughout  their  life  span  and  continue 
to  influence  the  way  in  which  hospital  personnel  view  the  quality  and  effectiveness  of 
the  ms.  (Safir,  1978,  p.  98) 

2.  HIS  Environmental  Oveniew 

Early  hospital  information  systems  were  developed  primarily  to  support 
hospital  administration.  Hospitals  applied  computer  resources  in  conventional  ways  for 
accounting  and  other  business  related  administration.  Computers  were  also  used  in 
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medical  research  but  were  not  generally  considered  suitable  for  directly  supporting  the 
medical  care  given  to  patients. 


Figure  6  (Cowey  and  McAlister,  1980,  p.  137)  shows  three  main  areas 
where  medical  computing  can  be  applied  in  a  hospital  environment.  The  two  large 
circles  represent  the  more  traditional  applications  of  computers  in  health  care, 
administration  and  research.  The  intersection  of  these  circles  represents  the  area  of 
medical  computing  related  to  the  care  provided  to  patients.  This  area  overlaps  both 
medical  research  computing  and  administrative  computing  and  is  affected  by  the 
conflicting  objectives  of  doctors  and  managers  discussed  earlier.  We  targeted  this  area 
of  medical  computing  in  our  research  and  found  a  tremendous  lag  in  the  computer 
technology  2q)plied  to  medical  care  delivery. 


Figure  6.  TTiree  Areas  of  Medical  Computing 
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Experts  in  both  the  medical  and  computer  Helds  began  to  recognize  the 
medical  computing  lag  in  the  mid-1970s  and  have  made  concerted  efforts  to  catch  up. 
A  Symposium  on  Computer  Applications  in  Medical  Care  (SCAMC)  has  met  annually 
since  1976.  In  1978,  hearings  were  held  before  the  Subcommittee  on  Domestic  and 
International  Scientific  Planning,  Analysis  and  Cooperation  to  discuss  the  topic  of 
computers  in  health  care.  The  reasons  for  the  medical  computing  lag  can  be  traced 
back  to  the  critical  nature  of  the  HIS  introduced  in  the  previous  section.  In  1978, 
Aran  Safir  M.D.  wrote: 

...the  complexity  that  characterizes  human  interactions  is  perhaps  nowhere  better 
demonstrated  than  in  the  relationship  of  doctor  and  patient.  Representing  such 
complex  human  interactions  effectively  within  the  computer  is  exceedingly 
difficult.  (Safir,  1978,  p.  98). 

In  1980,  Cowey  and  McAlister  found  it  was  rare  for  ho^itals  to  devote  a 
portion  of  its  budget  to  data  processing  equivalent  to  that  spent  by  most  other 
industries  of  comparable  size  (Cowey  and  McAlister,  1980,  p.  vi).  The  following 
barriers  to  medical  confuting  were  suggested  in  1985  by  Bonnie  Kaplan,  Ph.D.  at  the 
annual  SCAMC  symposium  (Kaplan,  1985,  p.  400): 

•  Lack  of  funding,  technology,  staffing,  training,  and  effort. 

•  Poor  management  including  difficulties  of  interdisciplinary  teams,  planning  and 
qjproach,  and  lack  of  attention  to  human  factors  and  methodologies. 

•  Difficulty  of  translating  medical  knowledge  into  a  form  suitable  for  computing. 

•  Institutional  constraints  and  physician  resistance. 

These  barriers  will  exist  to  some  degree  in  every  organization.  Many 
hospitals  are  attempting  to  hurdle  the  barriers  through  improved  conununication  and 
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cooperation  between  doctors  and  administrators.  Large  hospitals  are  moving  toward  a 
HIS  which  integrates  administrative,  research,  and  medical  service  computing  into  one 
complete  system.  An  example  of  an  integrated  HIS  is  the  University  Hospital 
Information  System  (UHIS),  introduced  in  1980  when  the  University  Hospital  at  State 
University  of  New  York  first  opened  its  doors.  UHIS  offered  a  wide  range  of  patient 
care  services  including  registration,  medical  records,  automated  lab  data,  quality  control, 
pharmacy,  radiology  and  nursing  (Vegoda  and  Dyro,  1986,  p.  261). 

The  medical  computing  future  shows  a  trend  toward  increased  integration  of 
hospital  information  system  functions  like  that  described  in  the  UHIS.  The  Yale-New 
Haven  Hospital  began  implementing  the  Patient  Care  Support  System  (PCSS)  in  1986. 
PCSS  is  expected  to  take  several  years  to  implement.  When  complete,  PCSS  is 
expected  to  improve  the  quality  of  care  rendered  to  patients  by  allowing  physicians  to 
more  efficiently  and  accurately  order  tests,  lab  work,  and  prescriptions.  Medical  record 
tracking  and  results  reporting  is  also  expected  to  improve  (Sadock,  1986,  p.  114). 

The  Department  of  Defense’s  answer  to  an  integrated  HIS  is  the  Composite 
Health  Care  System  (CHCS)  scheduled  for  completion  in  1991.  The  objectives  for 
CHCS  include:  "improving  the  quality  of  patient  care,  increasing  the  efficiency  of 
operations,  increasing  the  accuracy  and  availability  of  information,  and  providing 
standardized,  but  flexible  support."  (Regional  Training  Conference  Manual,  1988,  p. 
135).  In  1988,  a  Regional  Training  Conference  was  held  in  Monterey,  CA  to  update 
attending  medical  professionals  on  military  and  other  goverrunent  medical  information 
system  initiatives  (Regional  Training  Conference  Manual,  1988).  One  of  the  topics 
covered  at  the  conference  was  the  planned  implementation  of  CHCS.  The  following 
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patient  care  benefits  of  the  CHCS  were  cited  (Regional  Training  Conference  Manual, 
1988,  p.  140): 

•  Improved  quality  of  care. 

•  Reduced  time  spent  handling  information. 

•  Improved  management  control  of  operations. 

•  Increased  patient  satisfaction. 

•  Increased  compliance  with  standards  and  regulations. 

•  Increased  service  capacity  with  same  staff  levels. 

•  Improved  personnel  morale  and  job  satisfaction. 

Doctors  and  hospital  administrators  are  trying  to  recover  from  the  medical 
computing  lag  which  has  continually  plagued  the  industry.  They  are  beginning  to 
realize  the  importance  of  quality  information  for  providing  high  quality  patient  care. 
Integrated  HISs  are  the  future  for  medical  computing  and,  if  properly  used,  will  enable 
the  health  care  industry  to  provide  better  quality  medical  care. 

3.  Information  Technology  at  Silas  B.  Hays  Army  Community  Hospital 
The  current  information  technology  at  Silas  B.  Hays  Hospital  consists  of 
three  major  systems,  the  Medical  Expense  and  Performance  Reporting  System 
(MEPRS),  the  Automated  Quality  of  Care  Evaluation  Support  System  (AQCESS),  and 
the  Computer  Stored  Ambulatory  Record  System  (COSTARS).  These  three  systems  are 
completely  independent  and  are  maintained  through  separate  government  contracts.  No 
attempt  has  been  made  to  link  these  information  systems  into  one  large  database. 
Because  of  the  inherent  incompatibility  of  the  systems  and  the  eminent  arrival  of  the 
Composite  Health  Care  System,  SBHACH  admini.strators  believe  it  would  be  cost 
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prohibitive  to  attempt  systems  integration  at  this  time.  The  next  three  sections  describe 
the  basic  function  of  each  of  these  systems. 
a.  MEPRS 

The  purpose  of  MEPRS  is  to  collect,  process,  and  report  to  the  Health 
Services  Command  (HSC)  all  data  on  the  medical  workload,  staffing,  and  expenses 
incurred  by  each  woikcenter  within  the  hospital  (Regional  Training  Conference,  1988, 
p.  47).  Each  hospital  department  maintains  various  worksheets  to  record  manpower 
utilization  and  workcenter  expenses.  Each  department  reports  the  hours  for  clinicians 
(doctors)  and  non-clinicians  (all  others)  to  the  MEPRS  section,  a  subdivision  of  the 
Resource  Management  Division  (RMD).  Also  recorded  are  the  inpatient  bed  days  and 
the  number  of  outpatient  visits  for  each  of  the  woikcenters.  This  workload  information 
is  maintained  in  both  the  AQCESS  and  COSTARS  systems  but  because  the  systems 
are  incompatible,  the  data  must  be  manually  extracted  from  each  of  the  systems  for 
entry  into  the  MEPRS  system.  Direct  expense  data  on  such  items  as  electricity  and 
water  is  received  from  the  Fort  Ord  Finance  and  Accounting  Office  and  manually 
extracted  by  the  MEPRS  personnel  and  recalculated  based  on  the  square  footage  of 
each  departments’  assigned  space.  This  expense  information  is  then  manually  entered 
into  the  MEPRS  computer.  Each  month  all  hospital  data  is  loaded  onto  a  magnetic 
tape  aitd  sent  to  the  Health  Services  Command  (HSC)  at  Fon  Sam  Houston,  Texas. 
The  data  is  used  by  the  HSC  for  determining  funding  allotments  for  Silas  B.  Hays. 
The  information  maintained  in  the  MEPRS  system  is  not  considered  useful  to  the 
department  managers  because  it  is  not  kept  in  a  format  consistent  with  department 
resource  measures. 


27 


b.  AQCESS 


AQCESS  was  introduced  early  in  1986  for  all  Department  of  Defense 
Hospitals.  The  primary  purpose  of  the  system  was  to  provide  a  standardized  method 
for  the  collection  and  reporting  of  patient  and  provider  information  and  to  assist  in 
quality  assurance  decision  making  for  all  military  hospitals.  AQCESS  was  intended  to 
improve  the  quality  of  the  information  provided  to  administrators,  doctors,  and  quality 
assurance  persormel  and  to  save  hospital  staff  time.  Initially  implemented  with  three 
main  modules,  AQCESS  has  since  been  expanded  to  six  modules.  All  six  modules  are 
in  operation  at  Silas  B.  Hays: 

1.  Quality  Assurance  Module 

2.  Appointment  and  Scheduling  Module 

3.  Medical  Services  Accounts  Module 

4.  Clinical  Records  Module 

5.  Registration  Module 

6.  Emergency  Services  Module 

The  Appointment  and  Scheduling  Module  affects  each  individual 
department  the  most  as  it  determines  the  daily  workload  for  each  doctor  in  the 
department. 

The  AQCESS  system  is  used  to  capacity.  Although  ad  hoc  reports  can 
be  obtained  by  the  users  of  AQCESS,  only  the  system  manager  in  the  Information 
Management  Division  (IMD)  currently  uses  this  function.  The  system  is  heavily  used 
during  normal  working  hours  for  interactive  appointment  scheduling  and  clinical 
records.  To  help  keep  system  response  time  low  during  the  day,  all  AQCESS  reports 


are  generated  at  night  using  batch  processing.  The  AQCESS  modules  produce  many 
reports  which  show  hospital  operations  and  performance  in  many  areas.  Statistical 
reports  on  workload,  productivity,  and  appointment  scheduling  histories  are  just  a  few 
of  the  topics  covered. 

c.  COSTARS 

The  COSTAR  System  is  unique  to  the  Family  Practice  Clinic  at  Silas 
B.  Hays  Hospital.  This  system  receives,  records,  and  retrieves  administrative  and 
medical  information  for  the  active  duty  families  enrolled  in  the  Family  Practice 
Program  (Libra  Technology,  1982,  p.  2).  This  system  was  actually  a  prototype  system 
introduced  in  1982  and  initially  had  the  five  main  functions  described  below: 

•  Registration  -  This  function  allows  patients  to  be  enrolled  in  the  Family 
Practice  Program. 

•  Appointment  and  Scheduling  -  This  function  allows  the  COSTARS  data  entry 
clerk  to  book,  cancel,  or  view  appointments.  It  also  prints  daily  schedules  and 
appointment  lists  and  produces  a  pull  list  for  the  medical  records  department 
m^cating  which  patients  records  will  be  required  for  the  following  day’s 
appointments. 

•  Medical  Records  -  This  functions  maintains  a  history  of  a  patient  examination, 
including  administrative,  physical,  diagnostic  and  procedural  data. 

•  Pharmacy  Orders  -  This  function  was  intended  to  provide  full  pharmacy 
support  by  allowing  prescription  orders  to  be  automatically  forwarded  to  the 
pharmacy.  Records  on  pharmaceutical  history  were  also  to  be  kept  for  the 
patients.  Currently,  only  prescription  refills  are  managed  by  this  system. 

•  Laboratory  Orders  -  This  function  permits  physician  orders  for  lab  work  to 
be  automatically  sent  to  the  lab  before  the  patient  arrives.  Results  are  also 
entered  and  a  daily  report  is  sent  to  the  physician  showing  the  patient  and  the 
results  of  the  lab  tests  ordered  for  that  patient. 


Like  AQCESS,  the  COSTARS  system  maintains  a  large  data  base  and 
is  capable  of  producing  many  report.s.  COSTARS  also  accepts  ad  hoc  queries  but  none 


are  currently  being  used.  The  pharmacy  and  laboratory  functions  offer  capabilities  not 
found  in  AQCESS.  As  with  the  other  major  systems,  we  believe  this  system  is  not 
being  exploited  to  full  advantage.  This  system,  and  the  potential  benefits  of  the  data 
maintained  within  it,  are  discussed  further  in  subsequent  chapters. 

In  addition  to  the  three  major  information  systems  discussed  above, 
Silas  B.  Hays  makes  extensive  use  of  microcomputers  for  office  automation  and 
individual  data  processing  functions.  TTiese  computers  are  not  currently  networked  nor 
is  there  any  standardization  of  software  or  procedures. 

The  current  information  systems  available  at  Silas  B.  Hays  Hospital 
are  ciunbersome  and  cannot  be  integrated  to  provided  timely,  reliable,  and  useful 
information  to  hospital  decision  makers.  The  lack  of  integration  is  seen  as  a  major 
problem  by  many  hospital  personnel  and,  until  the  CHCS  comes  on  line,  stop-gap 
measures  are  being  used  to  fill  the  void  and  provide  the  best  information  available 
with  the  limited  resources. 

The  remainder  of  this  thesis  describes  how  one  department,  the 
Department  of  Family  Practice  and  Community  Medicine  (DFPCM),  uses  the  current 
information  systems  available  at  SBHACH.  Also  examined  is  the  need  for  an  improved 
system  and  how  these  improvements  might  be  realized  through  the  use  of  a  responsive 
microcomputer-based  information  system. 
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in.  CURRENT  SYSTEMS  ANALYSIS 


A.  INTRODUCTION 

Chapter  n  introduced  information  systems  development  methodologies  and  the 
application  of  information  systems  within  a  hospital  environment.  This  chapter 
describes  the  current  information  systems  in  the  Department  of  Family  Practice  and 
Community  Medicine,  using  the  development  principles  discussed  in  Chapter  H.  This 
chapter  introduces  data  flow  diagrams  as  a  pictorial  way  to  represent  the  existing 
information  system  and  presents  data  flow  diagrams  and  narrative  descriptions  for  the 
department’s  information  system. 

B.  THE  DEPARTMENT  OF  FAMILY  PRACTICE  AND  COMMUNITY 
MEDICINE 

Early  in  1988,  Health  Services  Command  approved  a  reorganization  for  Silas  B. 
Hays  Hospital  which  combined  the  Department  of  Family  Practice  with  the  Department 
of  Primary  Care  and  Community  Medicine,  creating  the  Department  of  Family  Practice 
and  Community  Medicine  (DFPCM).  This  new  department  is  the  hospitals  largest  and 
most  diverse  in  terms  of  both  the  services  it  provides  and  it’s  overall  affect  on  the 
hospital.  Figure  7  is  the  department’s  organization  chart.  The  department  has  three 
general  service  areas:  Family  Practice  and  Residency,  Primary  Care,  and  Consolidated 
Troop  and  Family  Member  Services.  These  are  further  divided  into  specialized  clinics 
(sometimes  referred  to  as  sections)  as  shown  in  the  chart.  All  of  these  clinics  are 
outpatient  oriented  and  are  literally  the  gateways  to  all  other  hospital  services  (e  g.. 
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Figure  7.  Organizational  Chart  for  DFPCM 

phannacy,  lab,  and  specialized  medical  departments).  The  DFPCM  affects  every  aspect 
of  the  hospital;  every  patient  treated  at  Silas  B.  Hays  must  first  be  seen  by  a  doctor 
working  in  one  of  the  DFPCM  clinics.  The  mission  of  the  DFPCM,  as  stated  in  the 
Health  Services  Command  Regulation  10-1,  is  "to  provide  diagnosis,  care,  and  treatment 
of  all  patients  commensurate  with  the  highest  standards  of  quality."  (HSC  Reg  10-1, 
1987,  p.  3-1)  The  task  of  accomplishing  this  mission  is  not  nearly  as  simple  as  the 
mission  statement  itself. 

The  size  of  the  department,  the  volume  of  work  done,  and  the  impact  on  overall 
hospital  resources  combine  to  create  a  highly  visible,  management  challenge.  The 
Chief  of  the  DFPCM  (currently  a  Lieutenant  Colonel)  is  responsible  for  meeting  this 
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challenge.  The  resources  he  commands  include  over  1 50  people  and  an  annual  budget 
of  nearly  half  a  million  dollars.  In  addition,  there  are  five  separate  service  locations, 
one  of  which  is  100  miles  from  the  main  hospital  (Fort  Hunter  Liggett).  Unfortunately, 
these  resources  are  limited  compared  with  the  task  at  hand.  Since  his  time  is 
extremely  valuable,  the  information  he  gets  should  be  summary  in  nature  in  order  that 
he  not  be  overwhelmed  with  meaningless  data,  and  yet  at  the  same  time,  complete 
enough  to  allow  him  to  make  infonned.  confident  decisions.  All  of  these  factors  must 
be  considered  when  designing  an  infoimation  system  for  use  by  the  Chief  of  the 
DFPCM. 

Initial  interviews  with  the  Department  Chief  allowed  us  to  identify  those 
management  areas  which  demand  the  greatest  attention  and  for  which  he  requires  the 
best  possible  information.  These  areas  fell  into  the  following  seven  broad  categories: 

•  Fiscal  Resources. 

•  Material  Resources. 

•  Persormel  and  Scheduling. 

•  Productivity. 

•  Patient  Satisfaction. 

•  Medical  Procedure  Suspense  Information. 

•  Patient  Check-In  and  Records  Procedures. 

The  last  two  areas  were  determined  to  be  beyond  the  scope  of  this  thesis  because 
of  time  constraints  and  the  inherent  size  and  complexity  of  the  projects  themselves. 
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The  Department  Chief  agreed  with  our  decision  and  prioritized  the  remaining  five  areas 
as  shown  below: 


•  Fiscal  Resources. 

•  Material  Resources. 

•  Personnel  and  Scheduling. 

•  Patient  Satisfaction. 

•  Productivity. 

The  remainder  of  this  thesis  describes  the  research  into  each  of  these  areas  and  the 
requirements  for  an  information  system  which  would  serve  the  Department  Chief  in 
making  management  decisions  concerning  these  key  areas. 

The  five  major  areas  listed  above  were  divided  into  the  following  six  specific 
systems: 

•  Budget  System. 

•  Equqrment  System. 

•  Personnel  System. 

•  Scheduling  System. 

•  Patient  Satisfaction  System. 

•  Productivity  System. 

The  following  section  describes  the  six  existing  information  systems  listed  above 
(with  diagrams  and  written  narrative)  and  how  information  is  gathered,  stored,  and 
presented  for  decision  making.  As  described  in  Chapter  IT,  the  current  system  should 
be  well  understood  before  any  attempt  i.s  made  to  improve  any  part  of  it.  Subsequent 
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chapters  discuss  where  and  why  improvements  are  needed  and  how  those  improvements 
can  be  achieved  through  system  redesign  and  automation. 


C.  DATA  FLOW  DIAGRAMS 

In  the  preliminary  description  of  the  infonnation  system  within  the  DFPCM,  we 
used  Data  Flow  Diagrams  (DFDs)  to  represent  the  current  system  to  department 
personnel.  The  Data  Flow  Diagram  enables  the  designer  to  describe  the  existing 
system  or  the  proposed  new  system  at  a  logical  level  without  considering  the  physical 
environment  in  which  the  data  flows  (e.g.,  telephone  calls,  maU,  etc.)  or  the  physical 
environment  in  which  the  data  is  stored  (e.g.,  card  file,  microfiche,  disk,  floppy  disk, 
or  tape).  (Atkas,  1987,  p.  57)  The  DFD  describes  the  system  as  a  network  of 
processes  (subsystems)  connected  to  each  other  and/or  to  data  stores,  sources  and  sinks. 
(Atkas,  1987,  p.  58)  The  basic  symbols  used  in  the  DFD’s  are  described  below. 

•  Data  Flow.  An  arrow  is  used  to  represent  either  the  flow  of  information  or 
objects.  Occurrences  of  the  data  flow  must  contain  data. 

•  Process.  A  rounded  rectangle  represents  a  process.  Processes  are  work 
performed  by  people,  machines,  or  computers  on  incoming  data  flows  to 
produce  outgoing  data  flows.  (Whitten,  Bendy,  and  Ho,  1986,  p.  226) 

•  External  Entity  or  Boundary.  A  square  is  used  to  represent  an  area  in 
which  data  originates  or  terminates.  In  essence,  the  sources  and  sinks  defme 
the  boundaries  of  the  system. 

•  Data  Store.  An  open-ended  rectangle  represents  a  store  of  information  or 
objects,  irrespective  of  the  storage  medium.  (Atkas,  1987,  p.  59) 
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The  components  of  the  information  system  correspond  to  the  DFD  symbols  as  follows 
(Whitten,  Bendy,  and  Ho,  1986,  p.  234): 

Information  System  Component  DFD  Symbol 

Data  (Input)  Data  Flow 

Information  (Output)  Data  Flow  Users 

Entity/Process  Methods/Procedures 

Process  Data  Storage  Data  Store 

Computer  Equipment  Process/Data  Store 

Computer  Programs  Process 

To  achieve  clarity,  DFD’s  are  prepared  at  several  levels.  The  highest  level  DFD 
is  the  "context  diagram,"  which  merely  shows  the  boundaries  of  the  system  under 
study.  The  processes  are  further  decomposed  as  necessary  into  lower  level  diagrams. 
(Atkas,  1987,  p.  68).  The  following  sections  use  DFD’s  to  illustrate  the  six  current 
information  systems. 

1.  Budget  System  (see  DFD,  Figure  8). 

The  Resource  Management  Division  (RMD)  receives  the  hospital’s  budget 
from  the  Health  Services  Command  on  an  annual  basis  via  the  MED  304  report. 
RMD  divides  this  budget  into  quarterly  budget  targets  for  each  department  and 
distributes  the  budget  allocations  at  the  beginning  of  each  quarter.  The  department 
Non-commissioned  Officer  in  Charge  (NCOIC)  (currently  a  Master  Sergeant)  is  the 
principle  administrator  of  all  incoming  budgetary  information.  He  serves  both  as  the 
Department  Chief’s  budget  administrator  and  the  clinics  central  point  of  contact  on  all 
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budgetary  matters.  This  practice  of  using  the  NCOIC  as  the  monitor  appears  to  be 
common  practice  throughout  the  hospital. 

Once  the  department’s  budget  is  received  from  RMD  it  is  allocated  by  the 
NCOIC  into  16  separate  accounts.  The  16  budget  accounts  reflect  the  current 
organizational  structure  with  a  few  exceptions  required  by  funding  needs.  The  16 
sections  are  listed  below: 

•  Primary  Care.  This  is  an  overall  budget  category  for  any  department  wide 
requirements. 

•  Family  Practice  Clinic.  This  is  the  eighth  floor  Family  Practice  clinic  at  the 
hospital. 

•  CTMC-Family  Practice.  This  is  the  Family  Practice  clinic  operated  at  the 
CTMC. 

•  Emergency  Medical  Services.  This  is  the  emergency  room  excluding  the 
ambulance  section  requirements. 

•  Ambulance  Section.  Supply  budget  for  the  ambulance  section  which  is  a 
subsection  of  the  emergency  room. 

•  Flight  Surgeon  Office. 

•  General  Outpatient  Clinic.  Serves  walk-in  patients  and  active  duty  sick  call 
in  the  Hospital. 

•  Presidio  of  Monterey-Health  Clinic.  Though  the  POM  clinic  is  run  by 
PRIMUS,  the  department  assigns  a  doctor  as  liaison  to  handle  sickcall  and 
official  military  matters  for  which  it  receives  department  funds. 

•  Con.solidated  Troop  Medical  Clinic  (CTMC).  Medical  care  for  7th  Light 
Infantry  Division  personnel. 

•  Battalion  Aid  Station.  TTiis  money  i.s  provided  to  the  Division  Medical 
Supply  Office  to  reimburse  medical  supplies  used  by  the  battalion  aid  stations 
throughout  the  division. 

•  Fort  Hunter  Liggett  Clinic. 
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•  CTMC  (Pathology).  Funds  in  this  category  pay  for  supplies  needed  by  the 
pathology  section  located  at  the  CTMC. 

•  CTMC  (Radiology).  Funds  in  this  category  pay  for  supplies  needed  by  the 
X-Ray  section  at  the  CTMC. 

•  CTMC  (Pharmacy).  Funds  in  this  category  pay  for  supplies  needed  by  the 
Pharmacy  Section  at  the  CTMC. 

•  CTMC  (Immunization).  Funds  in  this  category  pay  for  immunization 
supplies  for  the  CTMC. 

•  Battalion  Aid  Station  (Immunization).  Funds  in  this  category  pay  for 
immunization  supplies  used  by  the  battalion  aid  stations. 

Each  section  prepares  requisitions  and  monitors  its  expenditures  in  its  own 
Document  Control/Funds  Control  register  (DC/FC).  This  document  serves  as  a  record 
for  items  ordered  and  an  indicator  of  the  account’s  remaining  funds  once  the  supplies 
are  received.  The  DC/FC  register  is  currently  maintained  manually  in  each  clinic’s 
supply  section.  One  important  location  for  the  expenditure  of  supply  dollars  is  the  Self 
Service  Supply  Center  (SSSC).  The  SSSC  is  a  self  service  supply  point  for  certain 
office,  medical  and  computer  supplies.  These  supplies  are  charged  against  the 
individual  section’s  account  and  are  usually  recorded  on  a  weekly  recap  basis  by  an 
entry  into  the  DC/FC  register.  These  expenditures  are  reconciled  on  a  weekly  basis 
with  the  Detailed  Obligation  Report  (DOR).  This  report  confirms  correct  obligation 
amounts  and  recorded  orders.  Four  copies  of  the  DOR  are  received  weekly  from  RMD 
in  microfiche  form.  The  four  copies  are  distributed  to  the  CTMC,  Fort  Hunter  Liggett 
clinic,  the  main  Family  Practice  clinic,  and  the  department  NCOTC.  There  are  a 
limited  amount  of  DOR’s  available,  so  every  section  cannot  receive  it’s  own  copy. 
This  shortage  is  caused  by  a  number  of  microfiches  actually  delivered  to  RMD. 
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Figure  8.  Budget  System  Data  Flow  Diagram 


The  NCOIC  provides  the  Department  Chief  with  budget  information  via 


the  department  Budget  Status  Report  (see  Figure  9).  This  report  is  prepared  at  the 
beginning  of  the  quarter,  at  the  beginning  of  each  month,  and  on  a  recap  basis  at  the 


end  of  each  quarter  and  the  Fiscal  Year.  The  Budget  Status  Report  is  the  department’s 


principle  source  of  information  on  cuirent  budget  and  expenditure  status  for  each  of 
the  16  accounts.  The  report  is  currently  generated  using  a  LOTUS  1-2-3  spreadsheet 
program  maintained  by  the  NCOIC.  The  spreadsheet  printout  shows  expenditures  by 
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Figure  9.  Department  Budget  Status  Report 
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section,  their  uncommitted  hinds  and  appropriate  percentages  of  expenditures  for  the 
reporting  period.  The  printout  is  given  to  the  Chief  monthly  and  maintained  by  the 
NCOIC  in  a  file  on  a  microcomputer  disk. 


Monthly,  the  NCOIC  receives  a  month-end  report  from  RMD  that  reflects 
the  expenditures  by  medical  and  non-medical  categories  for  each  of  his  separate  clinics. 
The  month-end  report  is  used  to  update  the  Budget  Status  Report  for  review  by  the 
Department  Chief  and  the  section  chiefs.  The  principle  problem  with  this  system 
concerns  the  end  of  year  constraints.  As  the  end  of  the  year  approaches,  the 
expenditure  of  funds  becomes  crucial.  The  amount  that  is  reflected  in  the  month-end 
report  may  be  several  obligations  behind  the  actual  expenditures  recorded  in  the 
section’s  DC/FC  register.  This  requires  a  direct  matching  of  available  funds  by 
monitoring  the  sections  through  telephonic  expenditure  reports. 

Quarterly,  the  Resource  Information  Report  is  generated  to  be  used  in  a 
meeting  between  the  Department  Chief  and  his  section  chiefs  (see  Figure  10).  This 
report  serves  as  the  agenda  for  the  meeting.  The  primary  topic  in  this  meeting  is  the 
projected  budget  shortfalls  for  the  quarter  based  on  unforeseen  requirements. 

On  an  as  needed  basis,  the  Budget  and  Equipment  Analysis  and  Review 
report  (the  BEAR)  is  requested  from  the  section  chiefs.  This  report  reflects  much  the 
same  budget  information  contained  in  the  Resource  Information  Report  but  includes 
important  information  on  the  status  of  critical  department  equipment  such  as 
replacement  or  maintenance  requirements  (discussed  below).  The  BEAR  is  collected 
by  the  NCOIC  for  comments  and  delivered  to  the  Chief  for  his  review. 
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2.  Equipment  Procurement  System  (see  DFD,  Figure  11). 

The  equipment  requirements  for  the  department  are  interrelated  with  the 
budget  system  described  above  in  that  all  expenditures  for  equipment  must  be  budgeted 
and  tracked  within  that  system.  The  department’s  equipment  needs  occur  in  the  four 
areas  listed  below: 

•  Durable  Equipment.  This  includes  low  cost,  less  than  $1000,  equipment  that 
is  used  on  a  day  to  day  basis.  This  equipment  is  funded  through  the  normal 
supply  budget. 

•  Capital  Expense  Equipment  Program  (CEEP).  Medical  equipment  that 
costs  more  than  $1000  but  less  than  $5000.  The  budget  for  this  equipment 
is  maintained  by  RMD. 

•  Medical  Care  Support  Equipment  (MEDCASE).  Equipment  that  costs  more 
than  $5000.  This  budget  is  maintained  by  RMD. 

•  Computer/Electronic  Equipment.  Although  the  cost  of  this  equipment  is 
taken  out  of  the  department’s  budget,  the  tqjproval  to  order  it  comes  from 
outside  the  department  (discussed  below). 

The  primary  source  of  equipment  authorizations  is  the  Table  of  Distribution  and 
Allowances  (TDA)  which  shows  the  equipment  authorized  to  be  procured  and  held  by 
each  department  section.  Special  medical  equipment  not  included  in  the  TDA  must  be 
specifically  identified  and  requested  by  the  department. 

Each  section  identify  their  equipment  requirements  by  determining  equipment 
authorization  levels,  the  equipment  currently  on  hand,  the  status  of  equipment  on  order, 
and  the  equipment  that  requires  replacement.  The  sections  have  numerous  sources  they 
can  use  to  determine  the  status  of  their  equipment.  The  Logistics  Division’s  Property 
Management  Branch  maintains  property  records  for  all  equipment  held  by  each  section. 
They  also  produce  reports  on  the  stanis  of  equipment  on  order,  the  useful  life  of 
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equipment  on  hand,  and  the  number  of  years  the  equipment  has  been  extended  over  its 
defined  useful  life.  The  Medical  Maintenance  Division  maintains  cumulative  status 
reports  on  the  maintenance  performed  on  all  medical  equipment  along  with  the  one¬ 
time  expenditure  limit  which  defines  the  maximum  limit  for  future  repair  costs  for  each 
equipment  item.  This  information  is  critical  in  determining  if  a  piece  of  equipment  has 
exceeded  its  allowed  maintenance  expense. 

The  problem  with  all  of  these  reports  is  their  relative  inaccessibility  to  the 
sections.  The  reports  are  not  distributed  to  the  sections  and  the  maintenance  reports 
are  maintained  in  the  Medical  Maintenance  building,  separate  from  the  hospital. 
Because  of  these  difficulties,  not  all  sections  attempt  to  obtain  this  information. 
Another  major  factor  affecting  the  availability  of  this  information  is  that  the  reports  are 
not  divided  into  sections  or  departments  but  maintained  on  a  hospital-wide  basis. 

Often,  equipment  needs  are  not  identified  until  failure  of  the  old  equipment. 
The  Department  Chief  and  NCOIC  recently  created  the  Budget  and  Equipment  Analysis 
Report  (BEAR)  to  help  them  plan  for  equipment  expenditures  and  better  manage  their 
equipment  budget  (see  Figure  12).  This  report  will  be  completed  by  each  section  on 
an  annual  basis  to  identify  critical  equipment  needs.  The  BEAR  report  not  only 
identifies  critical  needs  but  was  intended  to  promote  interest  in  identifying  those  needs 
in  a  more  timely  manner.  The  sections  must  identify  their  replacement  requirements 
for  the  upcoming  fiscal  year  and  for  four  subsequent  years,  he  sections  also  report  the 
requirements  for  CEEP  and  MEDCASE  items,  along  with  the  status  of  equipment  on 
order. 
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Figure  II.  Equipment  System  Data  Flow  Diagram 


Once  the  section’s  requirements  are  identified  with  the  BEAR,  the 
Department  Chief,  in  conjunction  with  his  service  chiefs,  determines  the  priorities  for 
the  department.  The  appropriate  paperwork  is  completed  and  forwarded  to  the  RMD 
Logistics  Division  to  await  the  next  hospital  wide  Program  and  Budgeting  Advisory 
Committee  (PBAC).  The  PBAC  consists  of  key  hospital  personnel  who  review  and 
prioritize  MEDCASE  and  CEEP  requirements  for  each  department.  If  approved,  these 


items  go  onto  a  list  of  prioritized  and  approved  equipment,  either  MEDCASE  or  CEEP, 


and  await  the  availability  of  funds. 
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Figure  12.  Budget  and  Equipment  Analysis  Report  (BEAR) 
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(3)  STATVrSi 


Currently,  there  is  no  consolidated  list  of  the  department’s  needs  but  each 
section  maintains  its  OAvn  list.  The  only  source  of  consolidated  information  on 
equipment  needs  are  the  quarterly  Resource  Information  Reports,  discussed  in  the 
previous  section. 

Needs  for  electronic  and  communications  equipment  are  separately  identified 
by  each  section  on  an  Information  Capability  Request  (CAPR).  Once  the  CAPRs  are 
approved  by  the  Department  Chief,  they  must  be  countersigned  by  the  Chief, 
Information  Management  Division,  the  Deputy  Commander  for  Clinical  Services,  and 
eventually  by  the  Directorate  of  Information  Management  for  Fort  Ord  (DOIM).  Once 
approved,  it  is  the  responsibility  of  the  department  to  obtain  the  funds  and  order  the 
equipment. 

The  Department  Chief  needs  all  of  this  information  to  plan  for  equipment 
expenditures.  He  can  use  the  information  provided  by  his  sections  to  plead  his  case 
to  the  hospital  administrators  who  allocate  the  funding  dollars  for  his  department.  The 
"out  year"  information  provides  him  with  a  projection  of  future  equipment  needs  and 
helps  improve  the  department  budgets. 

3.  Personnel  System  (see  DFDs,  Figures  13  and  14) 

The  DFPCM  employs  more  than  150  people.  To  effectively  manage  these 
people,  the  Department  Chief  requires  personnel  information  in  three  main  areas: 
authorized  positions  and  vacancies,  educational  travel  funding  requirements,  and 
personnel  leave  and  temporary  duty  requests. 
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Each  department  in  the  hospital  is  authorized  a  certain  number  of  people, 
by  position,  based  on  the  Table  of  Distribution  and  Allowances  (TDA).  Tlie 
Department  NCOIC  uses  a  word  processing  program  to  keep  a  list  of  all  authorized 
positions,  both  Elled  and  vacant,  for  the  DFPCM.  This  list  contains  appropriate  TDA 
line  numbers  and  position  descriptions  plus  the  personal  data  for  all  assigned  persons 
(or  a  "vacant"  indication  if  the  position  is  unfilled).  On  an  as-needed  basis,  the 
NCOIC  prints  the  personnel  position  list  for  each  section.  Each  section  NCOIC,  if 
necessary,  updates  his  list  and  returns  it  to  the  Department  NCOIC  who  then  updates 
the  master  roster.  The  updated  master  roster  is  forwarded  to  the  Department  Chief  and 
is  also  sent  to  the  MEPRS  section  to  update  their  Position  Control  Roster. 


Figure  13.  Personnel  System  Data  Flow  Diagram 
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Figure  14.  Leave  and  TDY  Absence  Data  Flow  Diagram 

The  Continuing  Medical  Education  (CME)  program  provides  the  doctors 
within  the  hospital  the  necessary  funds  for  continuing  their  medical  education.  Each 
doctor  determines  his  or  her  educational  needs  and  prepares  a  CME  request  which 
includes  the  estimated  cost  of  travel.  These  requests  are  reconciled  with  the 
department’s  aUocated  CME  funds  anc  if  sufficient  funds  are  available,  the  request  is 
approved  by  the  Department  Chief  and  forwarded  to  the  Deputy  Commander  for 
Qinical  Support  (DCCS)  for  approval.  The  DCCS  publishes  a  master  list  of  doctors 
approved  for  CME  travel.  The  NCOIC  requires  each  doctor  who  has  completed  his 
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or  her  CME  travel  to  provide  a  copy  of  the  travel  claim  voucher.  Through  this 
information,  the  NCOIC  can  capture  actual  CME  costs  well  before  they  are  reported 
by  the  travel  personnel  at  finance  (which  can  be  one  to  three  months  after  the  travel). 
The  CME  funds  are  managed  closely  because  actual  costs  often  exceed  the  estimates 
originally  stated  in  the  request.  The  CME  funds  are  maintained  separately  from  supply 
funds. 

The  Department  Chief  expressed  a  desire  to  monitor  leave  and  temporary 
duty  (TDY)  status.  Leave  and  TDY  information  is  collected  in  two  separate  methods 
depending  on  the  person  involved  (see  Figure  14).  Doctors  send  leave  and  TDY 
requests  to  the  Department  Chief,  via  their  chain  of  command.  Requests  approved  by 
the  Chief  are  recorded  in  a  journal  kept  by  the  department  administration  section  and 
forwarded  to  the  DCCS.  The  doctor  must  also  notify  the  Assistant  Department  Chief 
(ADC)  of  any  planned  absences  for  scheduling  purposes  (see  Figure  9,  Scheduling). 
The  hospital  Personnel  Administration  Center  (PAC)  types  approved  requests  on  a 
Department  of  the  Army  (DA)  Form  31.  This  form  is  routed  through  the  hospital 
distribution  system  to  the  NCOIC  who  distributes  it  to  the  doctor’s  respective  section. 
Other  personnel  leave  and  TDY  requests  are  routed  through  the  Medical  Company 
chain  of  command.  After  approval  by  the  Medical  Company  First  Sergeant  and 
Commander,  these  requests  are  forwarded  to  the  PAC,  typed  on  a  DA  Form  31,  and 
distributed  via  the  department  NCOIC  to  the  appropriate  section. 

The  Department  Chief’s  main  concern  in  managing  personnel  is  planning  for 
position  vacancies  and  temporary  absences  due  to  leave  and  TDY.  Presently,  section 
chiefs  report  upcoming  losses  on  an  exception  basis  only,  primarily  when  the  position 
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involved  is  critical  to  section  operations.  The  PAC  has  the  capability  to  report  military 
personnel  losses  on  a  30,  60,  90,  120,  150,  180,  270,  and  300  day  basis,  but  this 
information  is  available  only  on  a  hospital-wide  basis. 

4.  Scheduling  System  (see  DFDs,  Figures  15  and  16) 

The  Department  Chief’s  primary  concern  for  scheduling  lies  in  two  clinics, 
the  Family  Practice  clinic  and  the  CTMC/FP  clinic.  Figures  15  and  16  show  the 
doctor  scheduling  process  as  it  currently  exists  in  each  of  these  clinics,  respectively. 
a.  Family  Practice  Scheduling 

The  Family  Practice  scheduling  system  involves  two  primary  schedules, 
the  On-Call  Schedule  and  the  Clinic  Schedule,  and  a  secondary  schedule,  the  Walk-In 
Schedule.  The  Assistant  Department  Chief  (ADC)  creates  each  of  these  schedules. 
This  process  is  very  subjective  and  difficult  to  define  precisely.  Each  of  the  following 
sections  describes  the  process  for  each  of  the  schedules  discussed  above. 

(1)  On-Call  Schedule.  The  On-Call  Schedule  establishes  which  doctor 
will  be  on-call  for  each  night  of  the  month.  The  On-Call  Schedule  affects  every  clinic 
within  the  department  except  the  Emergency  Medical  Services  which  have  their  own 
on-call  schedule.  To  create  this  schedule,  the  Assistant  Department  C!hief  (ADC) 
maintains  several  different  files  which  help  him  determine  which  doctor  to  schedule  for 
each  day. 

Every  clinic  has  a  minimum  number  of  doctors  which  are  required 
to  be  on  duty  each  day.  This  information  is  maintained  on  a  sheet  of  paper  in  the 
ADC’s  scheduling  folder  and  is  necessary  for  creating  the  On-Call  Schedule  because 
a  doctor  who  is  on-call  one  day  will  not  be  available  for  duty  the  following  day.  The 
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ADC  also  maintains  historical  data  for  each  doctor  showing  the  number  of  times  the 
doctor  has  been  on  call  on  holidays  and  weekends.  The  ADC  keeps  3"  x  5"  cards 
with  special  requirements  for  each  doctor  such  as  continuing  education,  or  conference 
dates  for  which  the  doctor  would  be  unavailable  for  on-call  duty.  The  doctors  must 
also  inform  the  ADC  when  they  are  requesting  leave  or  when  they  will  be  away  on 
temporary  duty  (TDY).  The  last  information  kept  by  the  ADC  is  a  cumulative 
monthly  tally  of  the  number  of  times  each  doctor  has  stood  on-call  duty  for  the  last 
calendar  year.  After  considering  all  of  this  information,  the  ADC  creates  the  On-Call 
Schedule  in  a  manner  which  will  be  fair  to  all  of  the  doctors  and  yet  fill  the 
requirements  for  on-call  duty  and  the  following  day’s  clinic  schedule.  The  on-call 
schedule  is  distributed  to  each  doctor,  the  patient  care  nursing  stations  on  each  ward, 
the  emergency  room,  and  the  Clinical  Support  Division.  In  addition,  the  on-call 
schedule  is  used  to  create  the  clinic  schedule  for  the  Family  Practice  doctors. 

(2)  Qinic  and  Walk-In  Schedules.  As  with  the  on-call  schedule,  the 
clinic  schedule  is  created  by  the  ADC  after  considering  all  of  the  information  relating 
to  doctor  availability.  Staff  doctors  have  a  permanent  clinic  schedule  for  each  month. 
This  is  affected  only  by  leave  requests  and  TDY  orders  from  the  doctors  themselves. 
The  AE)C  must  also  schedule  residents-in-training  for  clinic  duty.  Each  resident  is 
assigned  a  primary  location  for  each  month  by  the  Resident  Director.  The  ADC  keeps 
this  information  in  his  scheduling  folder  along  with  special  instnictions  for  each 
resident  from  his  assigned  clinic.  These  instructions,  on  3"  x  5"  cards,  contain 
information  on  the  daily  availability  of  the  resident  for  duty  in  the  Family  Practice 
clinic.  Also  affecting  the  clinic  schedule  is  the  previous  day’s  on-call  schedule:  the 
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doctor  who  was  on  call  the  previous  day  will  not  be  available  for  work  in  the  clinic 
on  tlie  day  in  question.  The  ADC  creates  the  clinic  schedule  based  on  the  number  of 
doctors  available  for  each  day  of  the  month.  The  final  clinic  schedule  is  submitted  to 
the  COSTARS  data  entry  clerk  so  the  appointment  system  can  be  updated  to  show 
which  doctors  will  be  available  to  see  patients  in  the  scheduled  month.  Also,  for  each 
day  on  the  clinic  schedule,  the  ADC  schedules  one  doctor  to  see  walk-in  patients. 
This  doctor  is  then  responsible,  on  the  day  assigned,  to  see  all  family  practice  patients 
who  could  not  get  an  appointment  but  required  immediate  care.  The  walk-in  schedule 
is  fltached  to  the  final  clinic  schedule  and  distributed  to  each  doctor. 


Fi^re  15.  Family  Practice  Scheduling  Data  Flow  Diagram 
b.  CTMC/FP  Clinic  Schedule 

The  Chief  of  the  CTMC/FP  clinic  completes  his  clinic  schedule  in 
much  the  same  manner  as  described  for  the  family  practice  clinic.  The  on-call 
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schedule  created  by  the  ADC  includes  CTMC/FP  doctors  and  therefore  impacts  the 
CTMC/FP  daily  clinic  schedule.  The  Chief  of  CTMC/FP  uses  the  previous  day’s  on- 
call  schedule  to  determine  which  doctor  will  not  be  available  for  duty  on  the  current 
day.  Additionally,  he  receives  each  of  the  CTMC/FP  doctors  leave  and  TDY  requests 
and  special  availability  requirements  which  he  maintains  in  one  log  book.  He  consults 
this  log  book  and  the  on-call  schedule  for  the  upcoming  month  to  create  the  CTMC/FP 
schedule  for  that  month.  He  distributes  this  schedule  to  each  doctor  and  one  copy  is 
sent  to  the  AQCESS  data  entry  clerk  who  updates  the  appointment  scheduling  database 
to  reflect  the  doctors  available  for  appointments  in  the  CTMC/FP  clinic  for  the 
upcoming  month. 

As  can  be  seen  from  the  previous  discussion,  the  scheduling  process 
is  subjective  and  dependent  on  the  historical  files  and  log  books  maintained  by  the 
clinic  schedulers.  The  most  difficult  part  of  this  process  is  obtaining  and  coordinating 
all  of  the  information  sources  which  affects  the  doctors’  availability  for  duty  on  any 
given  day  of  the  month.  The  ADC  estimated  that  it  required  3  to  4  hours  to  create 
the  monthly  schedules  because  of  the  many  factors  influencing  the  entire  process. 


DOCTOR 


<LEAV£/T0Y  REQ> 


FAMILY 
PRACTICE  ON 
CALL  SCHEDULE 


DOCTOR 
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LOG  BOOl.: 


<0N  CALL  SCHEDULE) 


kCTMC/FP  SCHEDULE) 


<SPECIAL  AVAIL  f«Q) 


CREATE 

-»1 CTMC/FP  CL 
SCHEDULE 


<CTMC/FP  SCHEDULE) 


Figure  16.  CTMC/FP  Scheduling  Data  Flow  Diagram 
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5.  Patient  Satisfaction  (see  DFD,  Figure  17) 

Determining  patient  satisfaction  is  a  subjective  process  and  is  currently 
performed  by  the  department’s  quality  assurance  representative.  The  QA  representative 
created  a  questionnaire  to  obtain  subjective  responses  from  patients  on  various  topics. 
The  patients  are  asked  to  resfrond  "Yes",  "No",  or  "Not  Applicable"  to  eleven  questions 
concerning  the  care  they  received  in  the  Family  Practice  clinic.  This  is  the  only  clinic 
currently  using  the  patient  satisfaction  survey. 


kftanitT  «td  tvilMlian  ripart) 


QA  neilPC 


Figure  17.  Patient  Satisfaction  Data  Flow  Diagram 


On  one  day  of  each  month,  the  doctors  in  the  FP  clinic  are  asked  to 


distribute  the  questionnaires  to  the  patients  they  see,  with  instructions  that  the  patient 


return  the  surveys  to  the  receptionist  at  the  nurses  station.  The  receptionist  gives  all 
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of  the  collected  surveys  to  the  QA  representative  who  then  calculates  the  percentage 
responses  for  each  of  the  questions  and  produces  Monitor  and  Evaluation  Reports. 


Each  Monitor  and  Evaluation  (M&E)  report  prepared  by  the  department 
QA  representative  represents  an  important  aspect  of  care  recognized  by  the  hospital  QA 
Division  (see  example,  Figure  18).  Each  question  in  the  survey  is  an  indicator  of  one 
of  these  important  aspects  of  care.  Each  question  (indicator)  has  an  assigned  threshold 
(listed  on  the  M&E  report)  which  the  clinic  desires  to  remain  above.  When  the  results 
of  the  survey  are  tallied,  the  QA  representative  pencils  in  the  patient  response  rate  for 
each  question  next  to  the  corresponding  threshold  on  the  M&E  report.  The  completed 
Monitor  and  Evaluation  report’s  are  used  as  an  indicator  of  how  successful  the 
department  was  in  reaching  the  thresholds  for  each  of  the  important  aspects  of  care. 

These  Monitor  and  Evaluation  reports  are  maintained  in  a  binder  kept 
by  the  QA  representative  and  are  used  at  the  monthly  QA  meetings  to  report  on  the 
general  level  of  patient  satisfaction  for  each  of  the  important  aspects  of  care.  No  other 
reports  are  created  using  the  information  obtained  from  the  questionnaires  and  trends 
in  patient  responses  are  not  maintained.  The  Department  Chief  does  not  receive  a 
copy  of  the  Monitor  and  Evaluation  reports  unless  he  requests  them. 

6.  Productivity  (see  DFD,  Figure  19) 

The  DFD  in  Figure  19  depicts  the  current  information  processes 
involve<3  in  reporting  productivity  for  the  DFPCM.  The  CTMC/FP  section  is  the  only 
section  reporting  productivity  to  the  Department  Chief.  The  primary  reason  for  this  is 
the  fact  that  the  CTMC  is  an  ancillary  service  specially  monitored  by  the  Clinical 
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MONITOR  &  EVALUATION 


SCOPE;  Patient  satisfaction 

IMPORTANT  ASPECT  OF  CARE:  patients  will  be  treated  courteously  and 
professionally  by  the  staff. 


INDICATORS; 

1 )  Survey  indicates  records  ready  at  the  front  desk  ‘>7^' 

2)  Survey  indicates  screening  pronpt  and  private  7- 

3)  Survey  indicates  waiting  time  will  be  30  min  or  less 


THRESHOLD 


SOURCE  OF  DATA:  patients'  survey 

METHOD  OF  COLLECTION:  Family  practice  receptions  clerk  provides 
patients  with  survey  to  be  completed  after  appoinment. 

WHO  TO  COLLECT  DATA;  Receptions  clerk  to  forward  to  nurse  or  QA 
co-ordinator 

SAMPLE  SIZE;  30 

TIME  FRAME:  One  day  per  month,  every  other  month  starting  with 
AugustSS 

Figure  18.  Monitor  and  Evaluation  Report 

Support  Division.  The  CTMC/FP  appointments  and  patient  visits  are  tracked  by  the 
AQCESS  system. 

The  AQCESS  system  produces  a  report  called  the  Validated 
Appointment  Roster  which  shows  the  actual  patients  seen  the  previous  day.  This  report 
is  sent  to  the  Clinical  Support  Division  which  counts  the  number  of  patients  actually 
seen  by  the  CTMC,  per  provider.  A  cumulative  total  is  kept  for  the  entire  month.  At 
the  end  of  the  month,  the  Clinical  Support  Division  enters  this  information  into  a 
LOTUS  1-2-3  spreadsheet.  The  resulting  productivity  reports  are  sent  to  the  Chief, 
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DFPCM.  These  reports  provide  information  on  daily,  weekly,  monthly,  quarterly,  and 
yearly  workload  in  tabular  and  graphical  formats.  Provider  productivity  is  also  reported 
in  a  tabular  report  showing  the  number  of  patients  seen  each  day,  by  provider,  for  the 
reported  month. 

Although  the  productivity  of  all  of  the  sections  is  not  directly  reported 
to  the  Chief,  the  data  necessary  for  producing  clinical  productivity  information  is 
gathered  by  each  section.  The  remaining  sections  use  either  AQCESS,  COSTARS  or 
manual  logs  for  gathering  workload  data.  Patient  visit  information  is  then  reported  to 
the  Patient  Administration  Division  (PAD).  PAD  collects  and  forwards  all  hospital 
workload  information  to  the  Health  Services  Command  on  the  MED  302  report  both 
electronically  and  in  paper  format.  This  report  is  used  in  the  formulation  of  future 
budgetary  allocations  to  the  hospital.  Figure  20  illustrates  how  the  various  department 
clinics  currently  input  their  workload  information  to  PAD.  All  of  the  workload  data 
collected  by  the  department’s  various  sections  is  also  stratified  according  to  patient 
demographics,  e.g.,  active  duty,  dependents,  retired,  service,  etc. 


(LI.  MOlN,  (SOI 


Figure  19.  Productivity  System  Data  Row  Diagram 


58 


The  Department  Chief  wants  productivity  information  for  all  of  his 
clinics,  similar  to  that  provided  to  him  by  the  Clinical  Support  Division  for  the 
CTMC/FP  clinic.  The  raw  data  for  creating  most  of  this  information  exists  in  the 


current  systems  but  is  not  being  used  because  of  time  and  personnel  constraints,  and 


other  factors  which  were  not  readily  identifiable. 


t  Input  visits  by  9P0intMnt  schttfuling 

IMdac  fort  310-1  khmc  visits  vorkshttll 


Figure  20.  Clinic  Workload  Data  Flow  Diagram 
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IV.  FUNCTIONAL  SPECIFICATIONS 


A.  INTRODUCTION 

Chapter  HI  presented  the  DFPCM’s  current  information  systems  relating  to  six 
specific  areas:  budget,  equipment  procurement,  jjersonnel,  scheduling,  patient 
satisfaction,  and  productivity.  This  chapter  sununarizes  the  current  system’s 
deficiencies  and  examines  the  failure  of  automation  to  meet  the  department’s 
information  requirements. 

Additionally,  this  chapter  proposes  general  improvements  for  each  of  the  six 
areas  and  discusses  the  impact  of  these  solutions,  and  the  impact  of  automation  on  the 
department’s  information  systems.  The  detailed  system  improvements  for  each  of  the 
information  systems  are  presented  fully  in  Chapter  V,  Requirements  Analysis. 

B.  CURRENT  INFORMATION  SYSTEM  DEFICIENCIES 

The  Chief  of  the  DFPCM  makes  many  decisions  which  affect  both  his  personnel 
and  resources,  and  greatly  impacts  the  entire  hospital.  The  nature  of  his  responsibilities 
and  the  span  of  control  he  is  required  to  exercise  place  additional  emphasis  on  the 
significance  of  these  decisions.  Facing  both  time  constraints  and  limited  resources,  he 
needs  the  right  information,  at  the  right  time,  and  in  the  best  format  to  accomplish  his 
objectives  and  meet  the  needs  of  the  department  and  the  hospital.  In  analyzing  the 
existing  department  information  system,  we  discovered  many  deficiencies  which  hinder 
the  Department  Chief’s  ability  to  make  informed  decisions. 
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In  general,  the  reports  and  other  information  the  Department  Chief  receives  are 
complex  and  difficult  to  quickly  comprehend  because  they  are  not  summary  in  nature. 
In  interviews  with  the  Department  Chief,  he  expressed  a  desire  for  information  which 
would  depict  long  term  trends  and  show  department  performance  over  a  predetermined 
period  of  time.  Much  of  the  information  he  gets  now  is  a  "snap-shot"  in  time  which 
does  not  allow  him  to  see  the  "bigger  picture"  without  pouring  through  many  similar 
reports.  In  a  few  cases,  the  data  is  simply  too  time  consuming  to  analyze  (e.g., 
budget,  equipment  and  personnel  information)  and,  therefore,  never  becomes  meaningful 
information  for  the  Department  Chief. 

In  addition  to  poor  information,  the  Department  Chief  occasionally  has  difficulty 
getting  enough  information.  One  of  the  Department  Chief’s  concerns  is  having  sound 
information  to  help  justify  his  decisions  to  higher  authorities  and  support  his  actions 
in  managing  resources  and ‘personnel.  Missing  information  due  to  informal  repotting 
standards  or  poor  data  collection  impedes  his  decision  abilities  in  these  areas. 

Another  concern  of  the  Department  Chief  is  the  importance  of  feedback.  The 
Department  Chief  feels  it  is  critical  for  each  section  to  receive  sufficient,  and  timely, 
feedback  on  theii  performance  to  allow  them  to  become  more  effective  and  efficient 
on  there  own  initiative.  The  sections  currently  receive  very  little  in  the  way  of 
constructive  feedback  and  the  information  they  do  get  is  prone  to  the  same  problems 
discussed  above. 

Unfortunately,  inconsistent  reporting  requirements  and  system  capabilities  exist 
throughout  the  department  so  that  each  section  is  substantially  different  from  the  others 
in  the  information  it  is  able  to  report.  This  contributes  to  many  of  the  problems 
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described  in  the  preceding  paragraphs.  Succinctly,  the  current  information  system  is 
not  meeting  the  requirements  of  the  Department  Chief.  We  feel  the  majority  of  these 
obstacles  can  be  attributed  to  limited  personnel  resources,  time  constraints,  and 
ultimately,  the  incompatibility  of  the  hospital’s  automated  information  systems. 

C.  THE  FAILURE  OF  AUTOMATION  TO  MEET  INFORMATION 
REQUIREMENTS 

Chapter  n  introduced  the  three  major  automated  information  systems  in  place  in 
the  hospital:  MEPRS,  AQCESS,  and  COSTARS.  These  systems  hold  huge  stores  of 
data  which  can  potentially  produce  meaningful  information.  In  addition  to  these 
medical  information  systems,  the  hospital  uses  other  Army- wide  systems  for  accounting 
and  logistical  data.  Microcomputers  are  scattered  throughout  the  hospital  providing 
individual  computing  capabilities  in  some  functional  areas.  With  all  of  these  resources 
at  hand  and  with  the  rapid  advance  in  information  systems  technology,  the  question 
arises,  "Why  hasn’t  automation  solved  the  information  problems  within  the  DFPCM?" 

There  are  many  reasons  why  the  automated  systems  at  Silas  B.  Hays  have  failed 
to  meet  the  information  needs  of  it’s  key  decision  makers.  The  primary  factors  which 
have  contributed  to  this  failure  are  listed  below: 

•  The  AQCESS,  MEPRS,  and  COSTARS  systems  are  independent  and 
incompatible  with  each  other.  Data  sharing  is  impractical  and  duplication  of 
data  collection  and  data  reporting  are  wasteful  of  time  and  resources. 

•  All  of  the  sections  within  the  department  do  not  use  the  same  system.  For 
instance,  the  Family  Practice  Clinic  uses  COSTARS  for  appointments  and 
patient  records  while  the  Consolidated  Troop  Medical  Clinic,  the  Family 
Practice  Clinic  at  the  Consolidated  Troop  Medical  Center,  and  the  General 
Outpatient  Qinic  use  AQCESS  for  appointments  and  patient  information.  The 
Fort  Hunter  Liggett  and  Presidio  of  Monterey  Clinics,  the  Emergency  Medical 
Services,  and  the  Flight  Surgeon’s  Office  are  completely  manual. 
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•  Much  of  the  data  kept  by  the  accounting  and  logistical  information  systems 
is  not  divided  by  departments  or  sections,  making  information  extraction 
difficult  and  time  consuming. 

•  The  method  of  inputs  to  the  various  systems  are  different,  making  it 
impossible  to  create  standards  for  data  collection  and  reporting. 

•  Hospital  personnel  are  not  adequately  educated  on  the  capabilities  of  the 
current  iiiformation  systems.  In  discussions  with  various  department  and 
hospital  personnel,  it  was  apparent  they  were  unaware  of  the  information 
available  to  them  or  of  the  procedures  required  to  obtain  the  information. 

•  The  reports  produced  by  these  systems  are  in  tabular  format  and  reflect  the 
data  for  one  period  of  time.  Trend  analysis  over  time  is  impossible  without 
further  manud  manipulation  of  the  data.  Summary  information  is  also  difficult 
to  obtain. 

Although  most  of  these  problems  are  unsolvable  within  the  scope  of  this  thesis, 
evaluating  the  difficulties  they  create  within  the  department’s  information  system  will 
assist  us  in  identifying  specific  requirements  for  an  improved  information  system. 

D.  PROPOSED  INFORMATION  SYSTEMS 

The  first  two  sections  of  this  chapter  addressed  the  overall  problems  which  exist 
in  the  current  information  system.  In  identifying  what  the  system  lacks,  we  have  thus 
helped  identify  what  an  improved  system  will  require: 

•  Consistent  data  collection  methods. 

•  Consolidated  information. 

•  Concise,  summary  reports  which  are  easy  to  read. 

•  Analysis  of  department  and  section  performance  trends  over  time. 

•  Easy  data  input  methods. 

•  Feedback  for  department  and  section  leaders. 
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•  Standard  reports. 

•  Complete  and  up  to  date  information. 

The  remainder  of  this  chapter  is  an  analysis  of  the  requirements  for  each  of  the 
specific  areas  described  in  Chapter  m.  Each  section  below  summarizes  the  solutions 
we  propose,  supported  by  the  Department  Chief’s  requests,  for  the  six  major  areas 
under  consideration. 

1.  Budget  Information  System 
a.  System  Deficiencies 

The  Department  Chief  has  a  budgetary  system  that  meets  only  his 
minimal  needs.  The  information  listed  below  is  provided  to  the  Department  Chief  in 
tabular  format  by  the  microcomputer  based  spreadsheet  program. 

•  Account  Processing  Code  (APC).  This  code  is  generated  by  the  Resource 
Management  Division  to  identify  separate  identified  fund  accounts.  A  single 
section  can  have  several  fund  accounts. 

•  Section  name.  The  name  the  department  assigns  to  each  APC  listed  above. 

•  Allocated  funds  for  the  Quarter.  The  funds  allocated  for  each  APC  for  the 
quarter. 

•  Supply  Expenditures  for  the  Month. 

•  Total  Department  Expenditures  for  the  Month. 

•  Total  Spent  this  Quarter  (cumulative) 

•  Uncommitted  Funds  this  Quarter. 

•  Funds  per  Month  (target  expenditure  for  the  .section). 

•  Percent  Spent  for  Month. 

•  Percent  Saved  for  Month.  This  percentage  is  calculated  by  subtracting  the 
percent  spent  for  the  month  from  100  percent. 
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•  Percent  Spent  for  Quarter. 

•  Percent  Saved  for  Quarter.  This  percentage  is  calculated  by  subtracting  the 
percent  spent  for  the  quarter  from  100  percent. 

This  information,  though  adequate,  does  not  provide  him  with  an  easUy  decipherable 

format  nor  the  capability  to  track  spending  habits  for  more  than  one  month.  The  data 

used  to  generate  the  report,  the  Month  End  Report,  is  accurate  but  does  not  necessarily 

reflect  any  recent  section  expendinires.  In  spite  of  this  problem,  the  information  from 

the  Month  End  Report  is  still  considered  accurate  enough  to  be  a  good  indicator  of 

expenditures  for  the  Department  Chief. 

The  Department  Chief  also  receives  budget  information  from  the  two 
intradepartmental  reports,  the  Resource  Information  Report  (RIR)  and  the  Budget  and 
Equipment  Analysis  Report  (BEAR).  The  budget  sections  of  these  reports  are  meant 
to  provide  the  Department  Chief  with  up  to  date  budget  information  that  is  not 
currently  reflected  on  the  monthly  budget  worksheet.  Though  these  reports  were 
designed  to  report  more  current  budget  information,  the  information  actually  reported 
on  the  RIR  and  BEAR  reports  is  a  duplicate  of  the  budget  information  already 
provided  on  the  budget  worksheet.  In  fact,  the  Department  NCOIC  stated  that  he  often 
recopies  the  budget  data  onto  the  reports  from  the  Month  End  Report. 

The  Department  NCOIC  currently  maintains  old  copies  of  each  budget 
report  on  computer  disks.  As  each  new  report  is  needed,  the  Department  NCOIC 
gathers  the  current  information  necessary'  to  complete  the  spreadsheet.  He  gathers  this 
data  from  either  the  current  Month  End  Report  or  in  the  case  of  a  quarterly  or  yearly 
recap  report,  from  previous  monthly  reports.  Once  this  new  spreadsheet  is  created  for 
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the  report,  he  enters  the  sections’  expenditures  for  the  period  into  the  spreadsheet.  The 
input  of  each  section’s  expenditure  requires  the  Department  NCOIC  to  search  through 
the  spreadsheet  and  And  the  location  where  the  information  must  be  entered.  Although 
this  process  is  not  necessarily  difficult,  it  is  cumbersome  and  requires  the  Department 
NCOIC  to  have  a  working  knowledge  of  both  the  spreadsheet’s  format  and  the 
application  program.  This  system  can  be  handled  by  a  highly  computer  literate 
individual  like  the  current  Department  NCOIC,  but  could  easily  become  unworkable 
under  a  different  NCOIC. 

Data  analysis  requiring  more  than  one  month’s  data  would  involve  the 
combination  of  several  separately  maintained  spreadsheets.  The  old  data  is  replaced 
each  time  a  new  report  is  created.  The  elimination  of  historical  data  makes  long  term 
trend  analysis  extremely  difficult  and  cumbersome. 
b.  Proposed  System  Improvements 

Data  entry  can  be  made  simpler  by  standardizing  the  screen  displays 
and  inputs  and  by  making  the  program  environment  transparent  to  the  user.  This  data 
can  also  be  maintained  in  a  more  accessible  format,  such  as  a  database,  for  ad  hoc 
inquiries.  Maintaining  the  data  within  one  consolidated  database  will  also  provide  the 
capability  to  do  long  term  analysis  of  expenditures.  This  abUity  to  access  the  data 
allows  the  sections  to  retrieve  information  on  their  performance  in  the  same  format  as 
seen  by  the  Department  Chief. 

The  data  output  can  be  improved  through  the  use  of  graphs.  The 
graphs  will  be  used  to  display  budgetary  trends  on  a  yearly  basis  which  provides  the 
Department  Chief  with  a  clearer  picture  of  the  budget  fluctuations  and  trends  over 
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time.  These  graphical  printouts  allow  better  analysis  of  the  budget  information  with  a 
lot  less  mental  manipulation  of  the  data.  Printed  tabular  reports  can  be  improved  by 
reorganizing  the  presentation  of  the  information. 
c.  Impact  of  Automation 

Dr.  Ertel  best  characterized  the  role  of  the  microcomputer  in  automation 
by  his  statement: 

The  proper  role  for  the  computer  is  to  do  what  it  does  best:  scan  large  numbers 

of  records.. .r£q}idly,  apply  its  infallible  memory  for  detail,  and  serve  as  a 

communications  link.  (Ertel,  1984,  p.  485) 

The  primary  goal  in  our  requirements  specification  is  to  avoid  the  creation  of  any 
additional  and  senseless  work.  This  means  avoiding  the  automation  of  something  that 
does  not  need  automating  while  automating  those  things  that  best  fit  the  advantages  of 
the  microcomputer. 

The  budget  system  is  already  automated,  though  only  in  a  limited  sense. 
The  improvements  described  in  the  previous  section  will  have  the  following  impact  on 
the  current  information  system: 

•  Simplification  of  the  input  process. 

•  The  capability  to  maintain  a  larger  database  to  facilitate  trend  analysis  and 
griq)hing. 

•  Enhance  the  information’s  worth  to  the  decision  maker. 

•  The  cs^ability  to  graph  the  data  versus  displaying  it  in  its  current  tabular 
format. 

•  Reduce  the  amount  of  time  the  person  who  receives  the  information  must 
spend  in  deciphering  the  data  to  turn  it  into  useful  information. 

•  Provide  for  a  user  friendly  system  that  will  not  require  the  user  to  master  a 
computer  or  to  learn  a  particular  applications  program. 
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•  Providing  the  user  with  a  menu  driven  work  environment  should  make  the 
transition  between  users  less  complicated. 

•  Enhance  the  choice  of  outputs  (the  ways  the  data  can  be  viewed)  for  the 
Department  Chief  and  his  sections. 

d.  Impact  of  Proposed  System 

The  information  provided  by  the  new  budget  information  system  will 
provide  the  decision  maker  with  a  more  succinct  view  of  the  budget  information  than 
he  currently  receives.  As  discussed  in  the  introductory  sections,  the  Department  Chiefs 
time  is  limited  and  the  ability  to  see  the  impact  of  information  quickly  without  any 
major  data  manipulations  is  critical.  The  addition  of  a  trend  analysis  capability  will 
provide  the  Department  Chief  with  the  ability  to  forecast  and  manage  his  future  budget 
requirements.  By  being  able  to  pictorially  depict  his  budget  trends  and  status,  the 
Chief  can  keep  himself,  his  subordinates,  and  his  superiors  better  informed. 

2.  Equipment  Procurement  System 
a.  System  Deficiencies 

The  current  equipment  needs  are  identified  through  three  sources:  the 
Resource  Information  Report  (RIR),  the  Budget  and  Equipment  Analysis  Report 
(BEAR),  and  the  Information  Capability  Request  (CAPR).  The  equipment  needs 
identified  by  each  of  the  department’s  sections  are  provided  by  the  equipment  sections 
of  the  RIR  and  BEAR  reports.  The  Department  Chief  identifies  new  automated 
equipment  requirements  through  the  Information  Capability  Requests  (CAPR). 

The  RIR  contains  the  following  equipment  information: 

•  Old  Equipment  Status. 

•  New  Equipment  Status. 
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•  Medical  Care  Support  Equipment  (MEDCASE)  items  (equipment  needed). 

•  Capital  Expense  Equipment  Program  (CEEP)  items  (equipment  needed). 

The  BEAR  contains  the  following  equipment  information: 

•  Equ^ment  to  be  replaced  (immediately,  within  one  year,  within  two  years,  and 
within  three  years). 

•  Money  needed  for  equipment  replacement  (immediately,  within  one  year, 
within  two  years,  and  within  three  years). 

•  Actual  approved  items  now  on  the  CEEP  and  MEDCASE  program  with  the 
date  item  ordered  and  its  projected  arrival  date. 

•  Pap>er  work  in  progress  for  placing  equipment  either  on  the  CEEP  or 
MEDCASE  programs  and  its  paperwork  status. 

The  problem  with  the  information  provided  in  the  RIR  and  BEAR  reports  is 

redundancy.  Each  report  seeks  to  collect  information  on  only  the  high  priority 

MEDCASE  and  CEEP  requirements  but  within  two  different  timeframes,  quarterly  for 

the  BEAR  and  monthly  for  the  RIR.  These  reports  provide  the  Department  Chief  with 

only  a  limited  look  at  his  equipment  needs  and  tend  to  track  only  those  needs  that  are 

the  most  urgent  (usually  only  MEDCASE  and  CEEP  items).  The  reports  do  not  give 

the  Department  Chief  a  consolidated  look  at  all  of  his  department’s  requirements.  This 

fragmented  approach  to  capturing  the  data  makes  it  an  intricate  process  for  the 

Department  Chief  to  estimate  his  future  equipment  needs.  Since  funds  are  limited,  the 

I>epartment  Chief  stated  that  he  needs  a  consolidated  listing  of  all  his  requirements  to 

set  replacement  priorities  throughout  the  department.  The  consolidation  of  this 

information  would  also  be  beneficial  when  bargaining  with  the  hospital’s  equipment 

acquisition  board  (Programmed  Budget  Advisory  Committee). 


The  CAPR  requests  provide  the  Department  Chief  with  the  following 

infonnation: 

•  Functional  area  supported,  i.e.,  automation,  communications,  records 
management,  printing^ublishing,  and  visual  infonnation. 

•  Justification  for  the  equipment. 

•  A  description  of  the  changes  and  the  reasons  for  the  change  to  the  existing 
service  (if  applicable). 

•  Source  of  funding  for  the  equipment. 

These  requests  are  only  tracked  as  they  are  generated. 

The  process  of  consolidating  the  equipment  requirements  identified  in 
the  BEAR,  RIR,  and  CAPR  requests  is  tedious  and  requires  the  Department  Chief  to 
manually  consolidate  all  the  section’s  separate  reports.  The  current  system  also  does 
not  allow  him  to  track  the  long  term  equipment  requirements  needed  to  determine  if 
there  are  department-wide  problems  in  the  acquisition  of  equipment. 

Other  equipment  needs  that  may  not  be  as  critical  are  not  tracked  or 
monitored.  In  addition,  the  Department  Chief  cannot  track  the  section’s  past  reported 
requirements  which  are  either  inadvertently  or  deliberately  not  listed  on  the  current 
report.  This  requires  him  to  either  remember  all  of  the  past  requests  or  manually 
search  through  the  old  RIR  and  BEAR  reports  to  obtain  this  information. 

The  status  of  high  priority  equipment  requests  are  reported  on  the 
BEAR  and  RIR  reports.  The  only  way  to  see  the  status  for  this  equipment  is  to  review 
each  section’s  RIR  and  BEAR  reports  for  this  information.  The  Department  Chief 
simply  does  not  have  the  time  to  do  this. 
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b.  Proposed  System  Improvements 

Any  solution  proposed  for  the  equipment  information  system  will 
undoubtably  create  some  additional  work  for  the  department.  Therefore,  the  primary 
consideration  for  the  new  equipment  information  system  will  be  ease  of  data  entry  and 
familiarity  with  the  entry  format.  The  greatest  improvement  to  the  current  system  can 
be  accomplished  by  the  creation  of  a  consolidated  database  where  all  equipment 
requests  can  be  recorded  and  easily  tracked.  To  identify  equipment  requirements,  the 
Department  NCGIC  suggested  the  following  types  of  information  be  used  in  the 
database; 

•  Item  description. 

•  National  Stock  Number. 

•  Section  requesting  the  equipment. 

•  Date  requested. 

•  Type  of  request  (MEDCASE,  CEEP,  CAPR,  Other). 

•  Priority  of  equipment  within  a  category. 

•  Urgency  of  need  (immediate,  one  year,  etc.). 

•  Quantity  desired. 

•  Unit  price  and  associated  extended  price. 

•  Status  of  request  (requisition  number). 

•  Cumulative  recap  of  required  expenditures. 

Once  an  item  is  deleted  from  the  active  database  due  to  the  delivery  of  the  equipment, 
its  data  should  be  relegated  to  a  historical  database  for  the  analysis  of  long  term 
equipment  trends. 
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The  design  of  the  user  interface  is  critical.  Once  again,  data  entry 
should  be  simple  and  straightforward.  The  outputs  can  reflect  either  a  recap  by 
equipment  category  or  a  consolidated  listing  of  all  equipment  requirements.  The  current 
reports  should  be  consolidated  into  a  single  report  and  standardized  and  simplified  to 
match  the  inputs  required  by  the  user  data  entry  interface.  The  system  should  be  built 
to  facilitate  ad  hoc  inquiries  on  the  database  and  to  do  limited  mathematical 
calculations  to  subtotal  categories  and  run  cumulative  totals  w'ithin  categories. 
c.  Impact  of  Automation 

The  equipment  procurement  information  system  is  not  currently 
automated.  The  most  far  reaching  impact  of  automating  this  system  will  be  the  work 
required  to  enter  data  from  the  consolidated  Resource  Information  Report  into  the  new 
equipment  database.  On  the  other  hand,  the  Department  Chief  considers  the 
availability  of  this  information  important  for  resource  management.  As  stated  earlier, 
a  well  designed  user  interface  should  limit  data  entry  to  the  format  recognized  in  the 
RIR.  Specifically,  automation  will: 

•  Provide  the  department  with  a  consolidated  listing  of  all  equipment 
requirements  and  the  capability  to  report  separate  categories  without  leaving 
the  database. 

•  Provide  the  Department  Chief  with  the  ability  to  request  the  information  in  the 
format  he  needs  for  a  particular  situation. 

•  Provide  a  historical  database  of  equipment  requirements  that  can  be  analyzed 
to  determine  equipment  procurement  trends  over  the  long  term. 

The  Department  Chief  currently  feels  that  the  benefits  associated  with  automation  in 

this  area  will  far  exceed  the  costs,  provided  the  user  interface  is  kept  simple. 
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d.  Impact  of  Proposed  System 


The  proposed  system  will  provide  the  Department  Chief  with  a 
consolidated  listing  of  all  his  sections’  equipment  requirements.  This  information  will 
provide  him  with  a  capability  to  sort  equipment  needs  by  cost,  category,  or  priority 
within  the  separate  equipment  categories,  e.g.,  CEEP,  MEDCASE,  etc.  In  this 
information  lies  the  ability  to  bargain  with  the  hospital  resourcing  committees  by 
having  the  information  readily  at  hand  and  in  a  format  which  will  facilitate  this  "give 
and  take"  environment.  By  knowing  all  of  his  requirements,  the  Chief  can  better 
manage  his  resources  to  meet  those  equipment  needs  that  are  the  most  critical  to  his 
department’s  success  With  his  limited  time,  the  consolidated  format  allows  him  to 
digest  the  information  quickly.  Through  the  listings  of  future  needs,  he  can  better  plan 
the  budgets  to  meet  those  needs.  This  new  system  will  serve  to  facilitate  unique 
information  needs  quickly  and  with  less  inconvenience  in  obtaining  that  data. 

3.  Personnel  System 

a.  System  Deficiencies 

As  discussed  in  the  previous  chapter,  the  Department  Chief  has  two 
areas  of  concern  with  the  personnel  information  system:  tracking  and  reporting 
manpower  levels  and  funding  for  the  Continuing  Medical  Education  (CME)  program. 

The  Department  Chief  currently  tracks  personnel  manning  levels  by 
maintaining  this  information  within  a  word  processing  shell  This  format  is  not  easy 
to  update.  It  limits  the  types  of  reports  you  can  generate  and  the  type  of  analysis  that 
can  be  done  on  the  data.  Without  an  ad  hoc  capability,  the  Department  Chief  must 
visualize  position  vacancies  by  scanning  the  complete  listing.  This  format  also  restricts 
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the  types  of  additional  data  that  can  be  maintained  with  the  personnel  listing,  i.e., 
doctor  patient  panels,  productivity  infonnation,  or  leave  and  absence  requests.  This 
also  precludes  any  data  interfaces  with  other  information  systems,  such  as  scheduling. 
The  update  process  is  complicated  in  that  it  involves  printing  the  entire  form  and  then 
cutting  the  report  into  individual  sections.  Likewise  a  section  which  requests  a  listing 
must  be  satisfied  with  a  department- wide  listing. 

The  CME  listing  is  currently  maintained  on  a  spreadsheet.  This  type 
of  format,  though  adequate,  hampers  the  ability  of  anyone  to  do  ad  hoc  analysis.  Any 
trend  analysis  beyond  the  current  year  is  limited.  A  person  unfamiliar  with  the 
application  program  may  have  difficulty  up>dating  the  CME  spreadsheet. 
h.  Proposed  System  Improvements 

The  current  personnel  listing  can  be  integrated  into  a  database  to 
provide  the  Department  Chief  with  the  capability  to  keep  critical  personnel  information. 
The  database  should  contain  the  following  database  files: 

•  Position  Information  (TDA  position,  authorization,  etc.). 

•  Personnel  Information  (Name,  SSN,  and  Known  Loss  Date). 

•  Personal  Information  (Protected,  including  address,  spouses  name,  children, 
birthday,  telephone  number,  etc.). 

•  Leave/Absence  Log  (Interfaces  with  CME  listing  and  scheduling  system,  but 
would  also  include  other  types  of  absences,  i.e.,  leaves,  emergency  leaves, 
other  TDY,  or  unusual  planned  absences). 

•  CME  listing.  (Interface  with  the  Doctor  listing  and  the  Absence  Log  hut  also 
include?  critical  CME  intormation,  i.e.,  estimated  costs,  actual  costs, 
qualification,  etc.). 
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The  various  relationships  between  the  database  files  can  be  kept  transparent  to  the  user. 
All  requested  reports  can  be  created  by  linking  the  needed  database  files.  The 
Department  Chief  will  have  access  to  a  list  of  planned  absences,  anticipated  losses,  and 
vacancies  that  he  did  not  have  previously.  The  consolidation  of  the  CME  listing  with 
the  personnel  listing  will  consolidate  the  data  entry  requirements  under  one  person, 
therefore  fteeing  critical  personnel  to  do  their  primary  jobs.  This  type  of  data  format 
facilitates  any  type  of  report  the  sections  or  the  Department  Chief  could  request.  In 
addition,  the  scheduler  can  receive  a  list  of  the  pi  armed  absences  and  not  have  to  rely 
on  verbal  notifications  from  the  doctors  (see  Section  D.4.,  Scheduling). 

Once  again,  by  building  a  user  interface  that  is  independent  of  the 
program  used,  the  requirement  for  any  application  programming  familiarity  is  no  longer 
necessary. 

The  current  system  requires  two  separate  routes  for  leave  requests, 
depending  on  the  person  requesting  leave.  The  flow  of  information  can  be  improved 
by  centralizing  all  the  data  entry  and  flows  for  leaves  into  one  location.  By 
centralizing  this  data  flow,  the  leave  requests,  as  well  as  personnel  updates,  can  be 
combined  to  avoid  the  redundancy  of  the  data  maintained. 
c.  Impact  of  Automation 

Automation  will  improve  the  system  in  the  following  areas: 

•  Improved  user  interface.  The  system  can  be  independent  of  the  knowledge  of 
the  user. 

•  The  choice  and  diversity  of  reporting  capabilities  will  be  enhanced. 

•  The  leave  log  is  currently  maintained  manually.  By  automating  this  log.  the 
data  can  be  linked  to  the  other  systems,  particularly  the  scheduling  system. 
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•  The  data  will  be  made  easier  to  maintain  and  to  up>date. 

•  The  Department  Chief  will  be  able  to  maintain  a  protected  personal  database 
on  his  personnel. 

•  The  need  to  consolidate  all  data  flows  through  one  central  location  will  involve 
changing  some  internal  procedures  within  the  department.  These  changes  must 
be  validated  to  meet  regulations  and  will  cause  some  jrersonnel  changes. 

•  The  initial  setup  will  be  costly  in  terms  of  the  database.  The  maintenance  of 
this  large  database  will  require  the  use  of  a  data  entry  clerk,  but  the  work  can 
be  minimized  by  a  well  designed  user  interface. 

d.  Impact  of  Proposed  System 

With  an  enhanced  database,  the  Department  Chief  can  maintain  the  type 
of  data  he  needs  to  track  his  personnel.  Through  a  vacancy  listing  and  the  anticipated 
loss  listing,  the  Department  Chief  can  always  know,  with  one  simple  listing,  the 
vacancies  or  projected  losses  that  exist  in  his  department.  This  information  can  then  be 
used  at  critical  hospital  meetings  to  quickly  identify  his  needs  in  a  straightforward 
format.  At  the  same  time,  the  addition  of  personal  information,  readily  accessible  to 
him,  makes  his  job  as  senior  counselor  easier.  The  absence  listing  gives  him  a  monthly 
listing  of  the  personnel  that  will  not  be  available  during  a  specified  time  pieriod.  This 
information  is  critical  for  monitoring  the  workload  throughout  the  department  and 
greatly  enhances  the  Department  Chiefs  ability  to  predict  periods  of  high  stress  due 
to  personnel  shortages.  The  management  of  CME  funds  will  always  remain  critical. 
Doctors  need  the  necessary  education  lo  keep  them  up  to  date  in  their  medical  practice 
but  in  periods  of  increasing  resource  constraints,  the  ability  to  predict  and  justify  these 
requirements  is  critical. 
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4.  Scheduling  System 

a.  System  Deficiencies 

Scheduling  is  a  complex,  subjective  process  requiring  a  great  deal  of 
independent  information.  In  the  existing  scheduling  system,  this  information  is 
collected  in  many  different  ways,  at  different  times,  and  in  different  formats.  This 
information  is  subjectively  interpreted  and  evaluated  to  produce  the  three  required 
Family  Practice  schedules  and  the  C7TMC/FP  schedules.  Specific  problem  areas  within 
the  current  scheduling  process  (as  shown  in  Chapter  HI,  Figures  15  and  16)  are  listed 
below: 

•  Doctor’s  leave  and  TDY  requests  are  verbal.  The  scheduler  depends  on  the 
individual  doctor  to  inform  him  of  upcoming  absences.  There  is  no  standard 
form  or  time  requirements  for  providing  this  information. 

•  The  independent  sources  of  information  are  maintained  informally,  i.e.,  some 
are  recorded  on  yellow  legal  paper,  other  information  is  kept  on  3"  x  5"  cards, 
and  still  others  are  typed  on  regular  white  paper. 

•  There  is  no  formal  instruction  for  the  collection  or  maintenance  of  the 
information  necessary  for  scheduling.  The  Assistant  Department  Chief  (ADC) 
currently  keeps  all  the  scheduling  paperwork  in  a  manda  folder  and  the 
CTMC/FP  chief  has  a  green  log  book  in  which  he  records  doctor  availability 
information. 

b.  Proposed  System  Improvements 

The  subjective  nature  of  the  scheduling  process  and  the  diverse  sources 
of  the  necessary  information  place  restrictions  on  the  improvements  which  can  be  made 
and  the  resulting  benefits  of  these  improvements.  We  feel  attempting  to  automate  the 
process,  in  this  case,  is  infeasible.  Automated  scheduling  applications  requires  integer 
programming  and  optimization  techniques  far  beyond  the  scope  of  this  thesis. 
Additionally,  complex  scheduling  algorithms  often  require  the  computing  power  of  a 
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mainframe  computer  for  the  rapid  calculations  and  reiterations  of  scheduling  models. 
(Lyons,  1983,  p.  438)  Therefore,  instead  of  concentrating  on  the  process  of  actually 
creating  the  schedule,  we  propose  improved  methods  of  collecting,  maintaining,  and 
assimilating  the  necessary  information.  Developing  a  scheduling  optimization  model 
could  be  the  subject  of  future  research. 

As  described  in  the  previous  section  on  the  Personnel  System,  an 
automated  leave/TDY  log  could  be  used  to  record  all  requests  for  leave  as  soon  as 
they  are  approved  by  the  Department  Chief.  A  simple  report  listing  each  doctor’s 
requested  leave  dates  could  be  produced  for  the  ADC  just  prior  to  the  creation  of  the 
following  month’s  schedule.  This  would  ensure  the  ADC  had  all  doctor’s  leave  and 
TDY  dates,  without  having  to  rely  on  verbal  information  or  "Post-it-Notes"  stuck  on 
his  office  door. 

In  evaluating  the  other  methods  for  collecting  and  maintaining  doctor 
information,  we  found  that  automation  would  again  be  infeasible.  In  this  case,  the 
department  schedulers  do  not  have  ready  access  to  microcomputers  and  will  probably 
not  have  access  in  the  near  future.  Additionally,  automating  manual  records  can 
sometimes  cause  more  work  than  it  saves.  For  instance,  in  keeping  the  monthly 
cumulative  tally  sheet  described  in  Chapter  in,  the  ADC  simply  puts  tick  marks  beside 
doctors  names  to  show  how  many  time.s  they  were  on  call  for  the  month.  If  this  tally 
sheet  were  automated,  what  now  takes  the  ADC  2  or  3  minutes  to  perform  might  take 
10  or  15  minutes  by  the  time  he  turns  the  computer  on,  loads  the  application  program, 
and  selects  and  updates  the  doctor’s  information. 
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Improvements  can  be  made,  however,  if  the  forms  for  recording  and 
reporting  information  are  standardized  and  a  more  formal  method  of  coordinating  the 
information  is  developed.  Using  the  monthly  cumulative  tally  sheet  to  illustrate, 
preprinted  forms  with  the  months  of  the  year  listed  across  the  top  and  the  doctors 
names  on  the  left  could  be  used  instead  of  the  handwritten  yellow  legal  paper.  Other 
forms  depicted  in  Chapter  III,  Figures  15  and  16  could  be  standardized  and  preprinted. 
This  would  make  formalizing  instructions  easier  and  would  positively  influence  the 
scheduler’s  assimilation  of  data  when  producing  the  schedules. 

Keeping  these  standardized  forms  in  a  folder  or  binder  is  sufficient,  as 
long  as  there  are  some  basic  instructions  on  where  to  get  the  printed  forms  (e.g.,  the 
department  secretary’s  office)  and  the  doctor’s  leave  report  so  that  a  newcomer  to  the 
job  will  not  revert  to  an  unorganized  system. 

c.  Impact  of  Automation 

As  presented  in  the  last  two  sections,  automating  the  scheduling  process 
for  the  DFPCM  would  be  infeasible  within  the  scope  of  this  thesis.  Where  automation 
would  benefit  the  scheduling  process  is  in  providing  consolidated  information 
concerning  doctor’s  leave  and  TDY  requests.  This  is  discussed  more  fully  in  the 
section  on  personnel.  The  preprinted  forms  for  standardizing  the  information  collection 
and  maintenance  functions  could  be  created  and  kept  on  a  floppy  disk  in  the 
department’s  administrative  office.  They  can  then  be  printed  as  needed  by  the  ADC. 

d.  Impact  of  Proposed  System 

The  improvements  suggested  for  the  scheduling  system  deal  mainly 
with  organization  and  standardization  of  the  information  collection,  maintenance,  and 
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reporting  functions.  Although  the  process  will  remain  virtually  the  same,  the 
schedulers  will  find  it  much  easier  to  gather  and  assimilate  the  data  concerning  the 
individual  doctor’s  availability  status.  Designing  a  good  manual  user  interface  (forms, 
reports,  instractions,  etc.),  like  designing  a  computer  user  interface  (menus,  data  entry 
forms,  reports,  screens)  is  important.  "You  will  learn  and  use  a  system  better  if  it  has 
a  consistent  user  interface."  (Burnett,  1988,  p.  29)  Organizing  and  standardizing  the 
various  forms  and  reports  will  assist  the  scheduler  in  recording,  finding,  and 
understanding  necessary  information.  It  will  also  be  much  easier  for  him  to  explain 
the  system  when  he  turns  the  scheduling  job  over  to  another  person,  as  often  happens 
in  the  military.  Clear  instructions  are  vital  for  a  good  transition  file. 

The  process  of  scheduling  department  doctors  will,  for  the  time  being, 
remain  a  subjective  decision  making  process.  Formalized  methods  of  collecting  and 
reporting  information,  however,  will  ease  the  process  by  allowing  the  department 
schedulers  to  more  rapidly  assess  the  information  presented  to  them. 

5.  Patient  Satisfaction  System 
a.  System  Deficiencies 

Patient  satisfaction  is  difficult  to  define  and  measure.  The  concept  of 
satisfaction  is  viewed  differently  by  each  patient  and  is  influenced  by  different  factors. 
One  person  may  base  satisfaction  on  the  courtesy  of  the  doctor,  another  on  the  amount 
of  time  he  had  to  wait  to  see  the  doctor.  Some  people  agree  that  hospital  satisfaction 
is  "the  consumer’s  overall  emotional  feelings  about  a  hospital  following  his  or  her 
visit"  (Swan,  and  others,  1987).  Because  of  the  differences  in  opinions  on  this  matter, 
it  is  important  to  identify  some  basic  dimensions  which  might  be  indicators  of 
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sirtisfaction.  The  evaluation  of  these  dimensions  can  then  be  determined  by  using  a 
questionnaire  to  measure  patient  opinion  on  the  various  dimensions.  It  is  also 
important  to  realize  that  "many  questionnaires  are  developed  not  with  the  intent  of 
determining  global  patient  satisfaction,  but  instead,  to  address  only  those  dimensions 
of  satisfaction  with  which  an  organization  is  willing  or  able  to  react".  (Pelletier,  1985) 

Applying  these  concepts  to  the  DFPCM  involved  evaluating  the 
effectiveness  of  the  current  patient  satisfaction  questionnaire  and  the  value  of  the 
information  it  provides. 

The  basic  content  of  the  current  questionnaire  closely  matches  the 
D^artment  Chiefs  desires.  Table  IV  shows  the  dimensions  of  satisfaction  perceived 
by  the  Department  Chief  as  necessary  for  effective  evaluation  of  patient  satisfaction. 
The  current  questionnaire  covers  most  of  these  dimensions  except  as  noted  in  Table  IV. 
The  questionnaire  lacks  two  important  features:  a  brief  explanation  of  the  purpose  of 
die  questionnaire;  and  instructions  for  completing  and  submitting  the  questionnaire.  The 
patient  currently  receives  verbal  instructions  from  the  doctor  distributing  the 
questionnaire.  These  instructions  will  vary  slightly  from  doctor  to  doctor. 

The  format  for  obtaining  patient  response  is  not  as  effective  as  it  could 
be.  Instead  of  "YES/NO"  questions,  the  Department  Chief  would  like  the  answers  to 
be  scaled,  e.g.,  options  from  poor  to  excellent  using  a  scale  of  one  to  five.  "YES/NO" 
questions  are  considered  too  restrictive  whUe  a  scale  indicates  a  degree  of  intensity 
(Duffe,  1985).  For  our  purposes,  a  scale  would  show  the  general  level  of  patient 
satisfaction  with  respect  to  the  given  dimensions. 
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Table  IV  DIMENSIONS  OF  SATISFACTION 


**  ACCESS  TO  CARE  How  long  K  takot  to  got  an  appointmant. 

WAITING  TIME  How  long  It  takas  to  saa  a  doctor. 

COURTESY  OF  STAFF  Doctors.  Nursas,  Clarks. 

UNDERSTAND  TREATMENT  Explanation  of  prooaduras. 

“  CUNICAL  ENVIRONMENT  Claanllnass  of  dlnic. 

PHYSICIAN  TIME  Adequacy  of  tima  spent  with  doctor. 

ALLOCATION 

GENERAL  SATISFACTION  General  opinion  of  the  care  racaivod  for  a  particular 

visit. 

**  Dimensions  not  Included  in  currant  quastlonnaira 

The  priiiiary  problem  with  the  existing  system  is  in  the  output  generated 
from  the  questiotmaire  results.  Each  question  is  treated  as  a  discrete  entity,  one 
indicator  of  an  important  aspect  of  care.  As  such,  only  one-time,  discrete  response 
rates  can  be  obtained  for  each  question.  Additionally,  the  questionnaire  results  are  not 
being  tracked  or  reported.  As  discussed  throughout  this  thesis,  the  E>epartment  Chief 
wants  summary  information  which  depicts  comparisons  and  trends.  The  Monitor  and 
Evaluation  reports  do  not  provide  this  information. 
b.  Proposed  System  Improvements 

There  are  two  basic  improvements  which  need  to  be  made  for  the 
patient  satisfaction  system.  First,  the  questionnaire  must  be  redesigned  to  include  all 
of  the  dimensions  of  satisfaction  identified  by  the  Department  Chief,  listed  in  Table  FV. 
This  redesign  must  also  incoiporate  the  desired  scales  for  applicable  questions.  In 
addition,  the  questionnaire  should  include  a  statement  of  purpose  and  instructions  to  the 
patient  on  how  to  complete  and  submit  the  questionnaire.  Although  some  literature 
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suggests  that  a  cover  letter  be  included  (Landry,  1987,  p.  16),  we  believe  a  simple  one 
page  questionnaire  will  be  received  better  by  the  patients  and  will  be  easier  to  collect 
and  review. 

Secondly,  the  results  of  the  questionnaire  need  to  be  reported  in  a  more 
meaningful,  effective  method.  The  Department  Chief  should  be  able  to  view  trend 
lines  and  other  graphical  information  to  determine  the  level  of  satisfaction  with  respect 
to  various  dimensions.  Comparing  the  dimensions,  when  appropriate,  should  also  be 
made  easier.  Providing  this  information  using  automation  would  require  the 
questionnaire  data  to  be  entered  into  a  computer  program  which  would  manipulate  and 
compute  the  desired  results  and  produce  the  desired  output. 
c.  Impact  of  Automation 

If  the  responses  in  the  questionnaire  are  coded,  the  patient  response  can 
be  easily  entered  into  a  computer.  Once  this  is  done,  the  application  program  would 
automatically  compute  the  results  and  print  or  display  the  desired  output  in  tabular  or 
graphical  form.  Automation  will  allow  rapid  trend  analysis  and  graph  generation  and 
provide  a  means  for  storing  historical  results  for  future  analysis  if  desired.  To  perform 
these  functions  manually  would  require  an  inordinate  amount  of  time  and  the  resulting 
benefits  would  thus  be  outweighed  by  the  costs.  The  Department  Chief  has  clearly 
stated  the  shortage  of  personnel  in  his  depaitment  precludes  implementing  any  system 
which  would  require  excessive  input  or  evaluation  time.  The  time  the  QA  representative 
now  spends  hand  calculating  the  results  of  the  current  questionnaire  would  be  converted 
to  time  spent  by  a  data  entry  clerk  entering  the  raw  data  from  the  returned 
questionnaires. 
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d.  Impact  of  Proposed  System 


The  proposals  outlined  above  will  improve  the  patient  satisfaction 
information  system  in  several  ways: 

•  A  questioimaire  which  is  easy  to  understand  and  complete  is  more  likely  to 
be  submitted  by  the  patients. 

•  Improved  questions  will  meet  the  Department  Chiers  stated  dimensions  of 
satisfaction. 

•  Redesigned  answer  formats  (scales)  will  provide  more  meaningful  information 
to  the  Department  Chief  on  the  level  of  satisfaction  of  the  patients. 

•  Automated  applications  will  free  the  QA  representative  from  the  time 
consuming  task  of  hand  calculating  the  response  rates  for  each  question. 

•  Through  automation,  improvements  in  data  analysis,  storage,  and  rq>orting  can 
be  realized  with  minimal  time  requirements. 

•  Producing  more  meaningful  reports  will  allow  the  Department  Chief  to  spend 
less  time  analyzing  the  data  and  draw  more  accurate  conclusions  from  the 
information  presented.  Trend  analysis  and  historical  comparisons  will  give 
indications  of  possible  problems  and  potential  improvements  in  the  care 
provided  by  the  department. 

6.  Productivity  System 

a.  System  Deficiencies 

The  main  problem  with  the  productivity  uiformation  system  is  that  only 
the  CTMC  and  CTMC/FP  clinics  are  being  monitored  for  productivity.  The 
Departmf  ^t  Chief  likes  most  of  the  tables  and  graphs  produced  by  the  Clinical  Support 
Division  for  the  CTMC  clinics  but  would  like  to  receive  this  information  for  each  of 
his  other  sections.  Unfortunately,  all  of  the  sections  do  not  use  the  same  system  to 
record  patient  visits  and  doctor  workload.  CTMC  uses  AQCESS,  Family  Practice  uses 
COSTARS,  and  other  sections  use  a  manual  system.  ITius,  to  provide  the  Chief  with 
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the  infoimation  he  desires  will  require  collecting  and  consolidating  the  clinic  and 
doctor  workload  statistics  from  each  separate  clinic. 
b.  Proposed  System  Improvements 

The  Department  Chief  is  interested  in  obtaining  productivity  information 
for  two  distinct  purposes:  monitoring  each  individual  doctor’s  workload  (based  on  the 
number  of  patients  seen),  and  monitoring  the  overall  workload  of  each  clinic  (based  on 
the  total  number  of  visits). 

Monitoring  each  doctor’s  productivity  was  determined  to  be  beyond  the 
scope  of  this  thesis  for  the  following  reasons: 

•  Only  clinics  using  automated  appointment  systems,  i.e.,  ACCESS  and 
COSTARS,  maintain  individual  doctor  workload  data. 

•  Productivity  information  for  each  doctor  would  be  impractical  to  obtain 
manually  t^cause  of  the  high  volume  of  patients  treated  by  each  clinic. 

•  The  appomtment  systems  use  different  measures  of  doctor  availability  and  do 
not  factor  in  doctor  absences,  e.g.,  leave  and  TDY,  when  computing  doctor 
workload.  These  disparities  result  in  inconsistencies  between  the  resulting 
doctor  productivity  figures. 

For  these  reasons,  individual  doctor  productivity  will  not  be  discussed  in  the  remainder 
of  the  thesis  but  could  be  the  subject  of  future  research. 

Overall  clinic  woikload  data,  in  terms  of  the  number  of  patient  visits, 
is  reported  monthly  by  each  section  to  the  Patient  Administration  Division  (PAD).  This 
information  is  already  mandatory  and  can  be  obtained  from  PAD  either  manually  from 
the  printed  MED  302  report  or  automatically  from  the  data  in  the  PAD  worksheet  (see 
discussion  in  Ch^ter  IE).  The  use  of  an  automated  data  capture  routine  will  preclude 
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the  sections  from  having  to  provide  another  copy  of  their  workload  reports  to  the 
department. 


The  improvements  necessary  to  obtain  the  clinic  productivity 
information  involve  collecting  all  of  the  section’s  visit  data  for  entry  into  an  overall 
department  system.  With  a  consolidated  database  of  department  visit  information, 
productivity  reports  can  be  produced  to  show  monthly  clinic  workload  and  yearly 
productivity  trends.  The  productivity  database  can  be  combined  with  the  budget 
database  to  produce  information  relating  department  and  clinic  monthly  expenditures 
to  monthly  workload  data. 

c.  Impact  of  Automation 

Automating  clinic  workload  reporting  would  result  in  the  following 

benefits: 

•  The  Chief  can  monitor  the  aggregate  workload,  by  section,  to  determine  trends 
in  patient  visits  and  the  need  to  shift  resources  to  meet  needs. 

•  The  department  will  be  able  to  monitor  its  workload  in  relation  to  its  budget. 

d.  Impact  of  Proposed  System 

The  aggregate  number  of  patient  visits  is  important  information.  The 
number  of  patients  seen  by  a  section  can  be  compared  with  the  dollar  amounts  of 
supplies  used  to  track  and  estimate  budget  requirements  and  justify  spending  patterns 
for  the  Department  Chief.  The  trends  and  seasonal  changes  in  patient  visits  can  be 
analyzed  over  time  to  assist  the  Department  Chief  in  planning  for  future  requirements. 
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V.  REQUIREMENTS  ANALYSIS 


A.  INTRODUCTION 

This  chiqjter  presents  the  requirements  analysis  for  the  DFPCM  information 
system.  These  requirements  were  determined  through  prototyping  as  discussed  in 
Chapter  11.  The  requirements  analysis  is  based  on  the  functional  specifications  for  each 
system  described  in  Chapter  TV  and  provides  a  more  detailed  look  at  the  inputs, 
outputs,  data  structures  and  user  interface.s  required  to  meet  the  functional 
specifications.  We  used  User  Concept  Diagrams  (UCDs),  described  in  the  following 
section,  to  depict  the  requirements  for  the  systems  and  aid  in  establishing  the 
prototypes. 

Having  analyzed  the  current  system  (Chapter  ID)  and  proposed  improvements 
(Chapter  IV),  the  requirements  analysis  is  the  first  step  toward  actually  building  an 
improved  information  system.  This  thesis  takes  the  requirements  analysis  phase  of  the 
development  life  cycle  through  one  iteration  of  the  requirements  prototype.  The 
number  of  iterations  which  will  ultimately  be  required  for  the  prototype  is  unknown 
and  will  vary  for  different  development  projects.  Once  the  prototypes  are  accepted  by 
the  users,  the  system  development  can  continue  with  design  and  implementation.  The 
remainder  of  the  chapter  presents  the  identified  requirements  for  the  DFPCM 
information  system. 
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B.  USER  CONCEPT  DIAGRAMS 

Chapter  in  introduced  data  flow  diagrams  as  a  way  to  depict  the  current 
information  system.  Although  DFD’s  are  being  used  extensively  by  systems  analysts, 
there  are  many  other  methods  available  for  relating  information  system  functions  and 
data  flows  to  the  user.  One  of  these  methods  is  the  User  Concept  Diagram  (UCD) 
developed  by  Charles  F.  Martin  in  1988. 

Martin  designed  UCDs  to  supplant  DFDs  for  representing  the  information  system 
to  the  user.  UCDs  have  several  advantages  over  DFDs.  These  advantages  result  from 
the  use  of  additional  symbols  to  represent  entities  and  interactions  not  present  in  DFDs. 
The  major  advantages  are  listed  below: 

•  External  entity  symbols  clearly  indicate  data  flows  into  and  out  of  the 
automated  system. 

•  The  use  of  multiple  symbols  for  external  entities  more  closely  depicts  the 
objects  they  are  intended  to  represent. 

•  The  intended  user  is  identified  with  his  type  of  interface  so  the  interactions 
of  the  system  can  be  designed  for  compatibility  with  intended  users. 

•  Symbols  can  be  easily  drawn  with  standard  flow  chart  templates  or  automated 
graphics  packages. 

•  Different  storage  and  output  mediums  can  be  easily  portrayed.  (Martin,  1988, 
pp.  65-84) 

Figure  21  shows  the  basic  UCD  symbols  (more  can  be  created  to  meet  a 
particular  analyst’s  needs).  Although  UCDs  use  more  symbols,  the  resulting  diagrams 
are  easier  to  explain  to  the  users  because  they  are  "pictorially  more  suggestive  of  the 
objects  they  represent"  (Martin,  1988,  p.  65).  We  found  this  to  be  true  in  our 
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interactions  with  the  DFPCM  users.  Thus,  in  the  requirements  analyses  that  follow, 
we  use  UCDs  to  depict  the  department’s  information  system  requirements. 


Automated 

function 


Screen  display 


Data  flow 


On-line  date 
store 


Hardcop>y  reports 


Diskette  storage  or 
O  communication  of  data 
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External  entities 


Off-line  data 
storage 


Indication  of 
intended  user  and 
type  of  workstation 


Indication  of  major 
user  and  machine 
interaction  with  the 
given  function 


Figure  21.  User  Concept  Diagrams 


C.  GENERAL  REQUIREMENTS 
1.  User  Interface  Design 

The  design  of  the  interface  is  perhaps  one  of  the  most  critical  aspects  in  the 
development  of  a  prototype  for  the  DFPCM.  "Ease  of  use",  "user  friendly",  and 
"ergonomic  design"  are  all  industry  buzzwords  that  simply  mean  one  thing;  make  the 


interface  work  for  the  user  in  the  way  they  expect  it  to  work  in  their  environment. 


Many  factors  determine  who  will  be  the  users  and  when  and  how  they  will  use  the 
system.  The  environment  at  the  hospital  provides  a  challenging  set  of  circumstances 
for  the  design  of  the  interface.  The  target  DFPCM  information  system  user  will  most 
likely  be  a  novice,  untrained  in  both  computers  and  applications  programs.  He  or  she 
will  not  have  the  time  to  learn  complicated  applications  program  because  of  many 
more  urgent  duties.  The  information  system  will  not  have  dedicated  data  entry  clerks 
and  will,  in  all  probability,  rely  on  the  availability  of  someone  who  has  other  pressing 
matters  at  hand. 

Martin’s  Human  Factors/Computer  Knowledge  Structure,  as  depicted  in  Table 
V,  served  as  the  basis  for  the  interface  designs  in  developing  the  initial  prototype 
(Martin,  1987,  p.  335). 

To  properly  humanize  software  through  the  use  of  ergonomic  design 
principles,  Knittle  and  Gardner  suggest  the  designer  follow  the  principles  listed  below 
(Knitde,  1987,  pp.  164-171): 

•  Minimize  worker  effort.  The  user  should  only  perform  essential, 
non-automatable  tasks,  avoiding  repetition  of  work  already  accomplished 
(Knittle,  1987,  p.  164).  All  inputs  should  be  in  the  format  that  the  user  is 
already  familiar  with,  i.e.,  a  commonly  used  written  form  or  report. 

•  Minimize  worker  memorization. 

•  Minimize  worker  frustration.  Keep  the  user  aware  of  delays  in  accomplishment 
and  if  necessary  give  them  progress  reports  (Knittle,  1987,  p.  166). 

•  Maximize  use  of  habit  patterns. 

•  Notify  users  of  problems  promptly. 

•  Maximize  worker  control  of  tasks. 

•  Maximize  task  support. 
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T»ble  V  HUMAN  FACTOR S/CO^>rPlTTER  KNO\\TEDGF.  STRUCTURE  (Martin  and 
Fuerst.  1987,  p.  335) 


Human  factor 

Human  subfactor 

User  computer  knowledge 
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Nature  of  message 
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Screen  format 
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w'ithout  prompt 

Help  function 

Procedures 

Full,  unsolicited 

Upon  request 

Values 

Full,  unsolicited 

Upon  request 

Response  time 

Mean 

Minimize  wthin 
variance 

Minimize 

Variance 

Minimize 

Minimize  wthin 
mean 

Path  process 

Menu  structure 

Depth 

Breadth 

Overall  screen 
density 

Minimize 

Maximize 

Soeen  design  is  another  aspect  of  humanizing  software.  Stahl  recommends  the 
following  guidelines  in  the  design  of  screens  which  support  user  friendliness.  (Stahl, 
1986,  p.  60). 

•  Do  not  crowd  the  screen,  "Good  screens  look  good." 

•  Use  highlighting,  blinking,  and  reverse  video  sparingly.  Ovemse  will  lead  to 
operator  fatigue. 
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•  Use  color  sparingly.  Color  is  an  appealing  and  proven  way  to  enhance 
computer  input.  The  following  foreground/background  screen  combinations  are 
listed  in  order  of  legibility,  from  the  most  legible  to  the  least  legible  (Ives, 
1982,  pp.  15-47). 

MOST  LEGIBLE  Black  on  Yellow 
Green  on  White 
Blue  on  White 
White  on  Blue 
Yellow  on  Black 
White  on  Red 
White  on  Orange 
White  on  Black 
Red  on  Yellow 
Green  on  Red 
Red  on  Green 

LEAST  LEGIBLE  Blue  on  Red 

•  Limit  the  amount  of  information  on  each  screen  to  what  is  necessary.  Do  not 
force  the  user  to  remember  things  from  one  screen  to  the  next. 

•  Minimize  key  strokes. 

•  Minimize  cursor  movement. 

•  Show  the  maximum  permissible  length  of  an  input  field  with  underscores, 
highlighting,  or  brackets. 

•  Keep  the  screen  consistent  with  paper  input  forms.  Although  all  information 
from  the  p^r  form  may  not  need  to  be  entered  on  the  screen,  the  screen 
should  follow  the  general  flow  of  information  on  the  paper  form.  (Kendall  and 
Kendall,  1988,  p.  484). 

Messages  to  the  user,  an  essential  element  in  user  friendly  screens,  should 
be:  (1)  consistently  positioned,  (2)  short,  meaningful,  common  and  fully  spelled  out, 
(3)  affirmative,  (4)  in  the  active  voice,  and  (5)  in  the  temporal  sequence  of  events. 
(Galitz,  1983,  p.  9). 

Another  aspect  of  interface  design  is  the  design  of  menus.  The  user  should 
be  able  to  identify  which  transactions  are  available  through  a  series  of  logically  related 
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and  relevant  events  common  to  a  menu  screen.  The  menu  screens  for  the  DFPCM 
information  systems  are  depicted  in  the  following  sections  by  the  use  of  Menu 
Hierarchy  Charts. 

2.  Standard  Interface  Designs 

Understanding  the  importance  of  a  good  user  interface,  we  designed  a  set 
of  standard  interfaces  for  getting  user  input  and  for  displaying  output  on  the  screen  for 
each  of  the  systems.  The  following  sections  describe  the  standard  input  and  output 
designs  which  are  applicable  to  all  of  the  systems.  Within  the  detailed  requirements 
for  each  system,  we  present  a  specific  description  of  the  data  required  for  the  inputs 
and  outputs  related  to  that  system.  Appendix  A,  the  Data  Dictionary,  contains  detailed 
information  about  the  data  structure  of  the  system’s  databases. 
a.  Input  Screens 

The  majority  of  the  input  screens  were  generated  with  a  commercially 
available  database  screen  generator.  The  screen  generator  displays  the  available  fields 
from  the  database  in  use  and  allows  the  analyst  to  load  and  position  the  desired  fields 
onto  the  screen  to  create  a  functional  input  format.  The  program  which  generates  this 
screen  is  saved  and  called  into  use  whenever  the  user  selects  an  input  option  from  one 
of  the  menu  systems.  Appendix  B  is  the  program  listing  of  all  of  the  format  screens 
for  the  DFPCM  information  system. 

The  screen  generator  allows  the  system  designer  to  easily  load  and 
msaiipulate  the  necessary  input  fields  to  create  good  user  interfaces.  The  screen 
formats  are  easy  to  change  to  suit  the  user’s  requirements,  making  the  generator  an 
invaluable  tool  when  prototyping  the  requirements  analysis.  Examples  of  each  of  the 
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input  screens  designed  are  included  with  the  detailed  requirements  analysis  for  each 
system,  with  a  description  of  the  necessary  input  fields. 

Other  standard  input  screens  are  those  used  to  accept  input  from  the 
user  necessary  for  identifying  further  processing  requirements,  such  as  the  year  and 
month  for  a  desired  report  or  a  person’s  identification  number  for  updating  his  or  her 
personal  information.  These  screens  are  created  with  programming  commands  which 
identify  where  the  prompts  and  input  blocks  appear  and  any  other  information  needed 
on  the  screen.  An  example  of  these  interactive  screens  is  shown  in  Figure  22.  Where 
possible,  we  have  designed  these  screens  to  position  prompts,  input  blocks,  and 
instructions  in  the  same  locations  and  with  similar  terminology.  Whenever  the  user  is 
asked  to  input  a  coded  response,  e.g.,  the  Section  Code  shown  in  the  example,  he  or 
she  should  be  allowed  to  view  a  help  screen  showing  the  valid  codes  for  that  particular 
item,  e.g.,  FPC  =  Family  Practice  Clinic. 

Enter  the  Year  for  report!  99 
Enter  the  Month  for  report;  10 

Enter  the  Clinic  aectlon  code  for  report!  FPC 

Figure  22.  Sample  Interactive  Input  Screen 
b.  Review  Screens 

In  many  of  the  system  menus,  there  is  an  option  for  reviewing  database 
information  on  the  screen.  The  review  screens  are  easily  created  with  commercially 
available  database  software  (e.g.,  DBASE  in+)  by  using  a  programming  command  and 
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^cifying  the  fields  desired  for  display.  An  example  of  a  typical  review  screen  used 
in  the  DI’PCM  information  system  is  shown  below. 


APC 

DESCRIPTION 

SECT  CODE  POC 

TELEPHONE 

W357 

FAM  PRAC  CUNIC 

FPC 

TURNER 

8888888 

W358 

CTMC-FPC 

CFP 

SHAW 

7777777 

W360 

EMERGENCY  MED 

EMS 

BLAKE 

6666666 

The  field  names  are  printed  across  the  top  of  the  screen,  in  the  order  given  in  the 
program  command.  The  specified  fields  for  each  t^licable  record  are  displayed 
beneath  the  corresponding  field  tide.  The  analyst  can  program  the  review  screen  to 
allow  the  user  to  change  certain  data  or  prevent  the  user  from  making  any  changes 
while  reviewing  the  database  information.  Review  screens  used  throughout  the  system 
are  similar  in  format.  The  specific  fields  required  for  display  for  each  review  are 
described  within  the  detailed  requirements  for  the  ^licable  system.  As  with 
generated  screen  inputs,  analysts  can  easily  update  review  screens  to  meet  user 
requirements  during  prototyping. 

3.  Requirement  Analysis  Constraints 

The  detailed  analyses  which  follow  describe  the  data  structiues,  menus, 
inputs,  outputs,  and  user  interactions  for  each  of  the  systems  under  consideration. 
Many  of  the  tables  and  grs^hs  produced  by  the  systems  require  extensive  data 
manipulations  and  in  some  cases,  interaction  with  more  than  one  software  package. 
The  design  of  the  detailed  programming  for  these  data  manipulations  and  extractions 
is  beyond  the  scope  of  this  thesis  and  is  therefore  not  included  in  the  detailed  system 
requirements.  The  output  examples  were  generated  using  sample  data  similar  to  that 
which  would  be  extraaed  from  the  database.  Where  applicable,  the  program  listings 
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for  each  system  contain  comment  statements  indicating  where  data  manipulations  and 
report  generation  would  have  to  occur  to  produce  the  desired  output.  Within  the 
system  requirements  is  a  detailed  descr^tion  of  the  data  elements  necessary  to  create 
the  outputs.  The  actual  method  of  output  generation  will  depend  on  the  software 
packages  used.  For  example,  if  the  database  software  has  graphing  ciq>ability,  the 
gr^hs  can  be  generated  internally  from  the  existing  data.  If  not,  the  data  will  have 
to  be  moved  to  a  separate  graphics  software  package  to  produce  the  desired  graphs. 
These  software  specific  constraints  are  not  included  as  part  of  the  requirements  analysis 
but  would  have  to  be  considered  further  in  the  development  life  cycle,  once  the  design 
and  software  selections  have  taken  place. 

D.  DETAILED  REQUIREMENTS 

1.  Budget  Information  System  (see  Program,  Appendix  C) 

Figure  23,  a  user  concept  diagram,  gives  a  picture  of  the  components  of  the 
new  budget  information  system.  The  user  concept  diagram,  as  discussed  in  the  previous 
section,  allowed  us  to  give  the  Department  Chief  a  general  picture  of  the  new 
requirements  necessary  for  the  budget  information  system. 
a.  Data  Structures 

To  successfully  meet  the  needs  of  the  Department  Chief,  the  data 
structure  for  the  budget  system  was  designed  to  provide  maximum  flexibility  in  data 
retrieval  and  analysis.  Each  database  was  designed  to  represent  a  portion  of  the  budget 
process,  e.g.,  the  receipt  of  the  quarter’s  budget  allocations  or  the  receipt  of  the 
section’s  expenditures  as  reported  in  the  month  end  report.  Figure  24  represents  how 
each  database  relates  with  the  other  databases  in  the  budget  information  system. 
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Report 


Figure  23.  Budget  Information  System  l^ser  Concept  Diagram 

TTie  structure  of  the  data  fields  facilitates  the  combination  of  databases 


through  the  use  of  relationships  among  the  key  fields  between  the  databases.  The  key 
field  identified  throughout  the  budget  databases  is  the  Account  Processing  Code  (APC) 
which  is  used  within  the  hospital  for  fmancial  accounting  purposes. 

The  APC  database  contains  the  following  data  fields: 

•  Account  Processing  Code.  Hospital-wide  funding  code. 

•  Section  Description.  This  is  the  specific  department  name  associated  with  a 
particular  APC  code. 

•  Section  Code.  This  field  was  designed  to  represent  the  true  organizational 
structure  of  the  department.  It  allows  the  system  to  interrelate  sections  along 
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orgatiizational  lines  versus  the  artificial  budgetary  lines  necessitated  by  the 
APC  funding  codes.  This  convention  allows  other  subsystems  of  the  DR’CM 
information  system  to  relate  budgetary  information  along  the  same  command 
lines,  such  as  is  necessary  in  the  Productivity  system.  The  codes  used  in  this 
field  include: 

DEP  IDepartment  Headquarters 

FPC  Family  Practice  Clinic,  Main  Hospital 
CFP  Family  Practice  Clinic,  Troop  Clinic 
GOC  General  Outpatient  Clinic 

EMS  Emergency  Medical  Services 

POM  Presidio  of  Monterey  Health  Clinic 

CTM  Consolidated  Troop  Medical  Clinic 

FHL  Fort  Hunter  Liggett  Qinic 

AMB  Ambulance  Section 

FSO  Flight  Surgeon  Office 

•  Point  of  Contact  for  budget  matters  within  the  section. 

•  Telephone  Number.  Self  Explanatory. 

•  Status  Code.  A  system  code,  either  "A"  for  active,  or  "I"  for  inactive.  This 
code  is  needed  to  allow  APCs  which  are  no  longer  in  use  (identified  by  an 
I)  to  continue  to  be  linked  with  budget  data  to  maintain  long  term  historical 
APC  information.  The  APC  code,  once  entered  into  the  system,  is  never 
deleted.  Only  active  APCs  (coded  A)  are  displayed  when  a  user  requests  an 
APC  listing. 

The  APC  Allocation  Database  contains  the  following  fields: 

•  APC  code.  Described  above. 

•  Fiscal  Year  (FY). 

•  Quarter.  The  quarter  of  the  given  fiscal  year. 

•  Allocation:  The  funds  allocation  for  the  APC  in  the  first  field  further 
delineated  by  the  Fiscal  Year  and  Quarter  fields. 

The  APC  Monthly  Expenditure  Database  contains  the  following  fields: 

•  APC  code,  as  described  earlier. 

•  Fiscal  Year  of  expenditure. 
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•  Month  of  expenditure. 

•  Quarter  of  expenditure,  confuted  from  the  month  field,  i.e.,  if  month  is  10, 
quarter  is  1. 

•  Expenditure  for  the  month. 


APC  INFORMATION  DATABASE 


HOKTHLY  CXP£KDlTtm£  DATABASE 


Figure  24.  Budget  Information  System  Data  Structures 
h.  Data  Inputs 

The  user  will  be  required  to  maintain  the  databases  discussed  above 
through  three  database  interfaces.  The  three  interfaces  are: 

•  Enter  or  delete  quarterly  allocations. 

•  Enter  or  delete  monthly  expwnditiu'es  for  each  section. 

•  Enter  or  change  the  status  of  a  section’s  APC  infoimation. 

The  menu  hierarchy  chart  is  depicted  in  Figure  25.  As  discussed  in  the 
previous  section  of  this  chapter,  the  user  is  required  to  enter  the  fiscal  year  to  limit  the 
database  search.  If  necessary,  the  month  or  quarter  within  the  selected  fiscal  year  is 
also  entered.  These  entries  are  standardized  as  discussed  in  Section  C,  General 


Requirements.  All  entries  within  a  particular  menu  cycle  are  restricted  to  rtte  user’s 
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chosen  fiscal  year.  This  restriction  is  desired  because  most  data  entries  will  require  the 
same  fiscal  year  since  the  user  usually  works  in  one  fiscal  year  at  a  time.  To  change 
fiscal  year  while  working  in  the  selected  menu,  the  user  must  return  to  the  main  menu 
and  enter  the  new  fiscal  year  when  prompted.  The  entries  within  the  selected  menu 
cycle  are  limited  to  the  chosen  fiscal  year  so  the  user  does  not  have  to  re-enter  the 
fiscal  year  for  each  additional  expenditure  or  similar  input. 

In  the  cases  where  the  APC  is  entered  by  the  user,  the  system  verifies 
the  code  entered  against  the  active  APC  information  database  and,  if  the  APC  is  found, 
confirms  the  user’s  choice  with  the  following  screen. 

Section;  ■■■■■■■■■■  Section  Code:  m 
Point  of  Contact;  m||||mi|||m 

This  confirmation  prevents  the  entry  of  either  a  wrong  or  inappropriate  APCs  that 
would  destroy  the  integrity  of  the  allocation  and  expenditure  databases.  If  the  APC  is 
not  found,  an  appropriate  warning  is  issued  to  the  user  and  he  or  she  is  allowed  to 
try  again. 

Figure  26  is  a  picture  of  the  user  input  screen  used  for  the  entry  and 
deletion  of  a  quarter’s  budget  allocation  for  a  given  APC.  The  fiscal  year,  APC,  and 
quarter  have  already  been  entered  by  the  user  and  will  appear  on  the  input  screen. 
This  screen  is  modified  when  used  in  the  deletion  process  by  the  addition  of  a 
comment.  Delete  this  Record?  (Y/N)  |  ,  at  the  bottom  of  the  screen. 

Figure  27  depicts  the  user  input  screen  that  allows  the  user  to  enter  the 
monthly  expenditures  for  a  particular  APC.  As  discussed  previously,  the  user  can  only 
enter  the  actual  allocation  for  the  month.  The  month  and  APC  have  already  been 
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ALLOCATIONS 
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MONTHLY 
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AOO 

EXPENDITURES 

CHANCE 
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CHANCE 

EXPENDITURES 

REMOVE 

ALLOCATIONS 

REMOVE 

_  EXPENDITURES 

REVIEW 

ALLOCATIONS 

REVIEW 

.  expenditures 

BUDGET  SYSTEM 
Section  2 


Figure  25.  Budget  Information  System  Menu  Hierarchy  Chart 
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entered  and  verified  to  be  correct.  TTiis  format,  modified  like  the  quarterly  format,  is 
also  used  for  verification  prior  to  the  deletion  of  a  record. 


Figure  26.  Quarterly  Budget  Allocation  Input  Screen 


Enter  the  Monthly  Expenditure 


L 


AFC  Code 

Month 

Expenses 


W-156 

10 


Figure  27.  Monthly  Expenditure  Input  Screen 

Figure  28  depicts  the  user  input  screen  that  allows  the  user  to  enter  or 
change  an  APC.  The  entry  of  a  new  APC  is  preceded  by  verification  that  the  APC 
requested  is  not  in  the  current  database.  If  the  requested  APC  is  found  in  the  existing 
database,  the  user  is  warned  and  allowed  to  try  again.  The  user  is  not  allowed  to 
reenter  the  APC  once  the  screen  in  Figure  28  is  presented.  This  prevents  redundancy 
in  data  entry  and  keeps  the  user  from  circumventing  the  duplicate  APC  check 
procedure.  The  section  codes  are  displayed  on  the  screen  to  facilitate  user  entries. 
Inactivation  of  the  APC  is  allowed  when  the  user  is  prompted  with  "Do  you  wish  to 
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put  this  APC  into  inactive  status?  (Y/N)  |  If  the  user  wants  to  change  a 
particular  APC’s  status  code  to  inactive,  the  APC  record  is  automatically  annotated 
with  the  new  status  code.  Activation  to  an  active  status  is  automatic  when  the  user  first 
enters  a  new  APC. 


AFC  Code  Entered  ->  H-140 


SECTION 


Section  Code 


Point  of  Contact 
Telephone  Number  (H* ' 


Family  Practice  Clinic 
General  Outpatient  Clinic 
CTMC-Family  Practice 
Emergency  Medical  Service 
Presidio  of  Monterey 


SECTION  CODES 


FFC  Consolidated  Troop  Clinic  CTM 
GOC  Fort  Hunter  Liggett  Clinic  FHL 
CFP  Ambulance  Section  AMB 
EMS  Flight  Surgeon  Office  FSO 
POM  Department  _  P'El' 


Figure  28.  APC  Information  Input  Screen 


c.  Outputs 

Outputs  are  divided  into  two  general  categories.  Review  screens 
(discussed  in  Section  B  of  this  chapter)  and  pre-formated  reports.  The  three  general 
review  screens  presented  to  the  user  are  depicted  in  the  menu  hierarchy  chart  in  Figure 
25  as  the  menu  options  either  to  review  allocations,  expenditures,  or  all  of  the  APC 
infoimation.  Each  review  option  provides  the  user  with  the  generic  review  display 
as  described  in  Section  B  of  this  chapter.  The  data  fields  presented  in  each  case  are 
the  complete  data  fields  of  the  respective  artive  database. 

(1)  Monthly  Budget  Expenditure  Report.  Figure  29  is  an  illustration 
of  the  monthly  budget  expenditure  report.  This  report  serves  as  the  Department  Chief’s 
indicator  of  the  month  to  month  status  of  the  department’s  budget.  This  report  is 
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critical  to  the  monitoring  of  the  section’s  conq}liance  with  the  department’s  budget. 
This  report  is  also  provided  to  the  section  chiefs  for  the  same  reason. 

The  user  is  prompted  to  enter  the  fiscal  year  and  month  desired 
prior  to  the  output  of  this  report.  The  databases  and  q>propriate  fields  necessary  to 
create  the  report  are  listed  below. 

•  APC,  extracted  from  the  Monthly  expenditure  database. 

•  Section  Description.  This  information  is  obtained  from  the  combination  of  the 
APC  database  with  the  Monthly  Expenditure  database  to  obtain  the  title  for 
each  APC  in  the  monthly  expenditure  database. 

•  Allocation  for  the  quarter.  The  APC’s  allocation  figure  from  the  allocation 
database  is  combined  with  the  monthly  expenditure  database  for  the  selected 
fiscal  year  and  quarter. 

•  Expenditures  for  the  month.  This  data  is  derived  for  each  APC  fi-om  the 
monthly  expenditures  database. 

The  following  numbered  items,  which  clarify  the  calculated  fields 
within  the  report,  correspond  with  the  numbers  in  Figure  29. 

1  This  is  the  fiscal  year  of  the  report. 

2  This  is  the  month  of  the  report.  The  numerical  month  requested  is  converted 
to  the  name  of  the  month,  i.e.,  month  10  becomes  October. 

3  Quarter  of  the  report. 

4  Report  date  provided  by  the  system. 

5  Spent  for  Quarter.  This  field  is  calculated  by  summing  all  the  monthly 
expenditures  for  the  specified  quarter.  For  instance,  if  the  monthly  report  is  for 
November,  the  system  searches  the  monthly  expenditure  database  and  finds  all 
expenditures  for  the  first  quarter’s  months;  October,  November,  and  December. 
(Note:  in  this  example,  December’s  expenditures  would  be  zero.) 
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f?)  Month  JULY« - 

Oapartnant  of  Family  Practlc* 
Monthly  Expondlcuro  Roport 

Fiscal  Yaar 
Raport  Data 

7/20/89 

ARC  INFORMATION 

QUARTER 

^  MONTH 

APC 

SECTION 

ALLOCATED 

Ofi 

■B! 

FUNDS 

PER  MONTH 

Bin 

i 

«1«0  PRIMARY  CARE  4000.00  3000.00  75  «  1333.33  36.36  03  % 
¥357  RAM  PRAC  CL  9000.00  9500.00  106  %  3000.00  3100.00  ••  103  % 
¥360  EMERG  MED  SERVICE  30000.00  5000.00  17  %  10000.00  11000.00  •*  110  % 

d)  ^  (i)  (5^-  ^ 


DEPARTMENT  TOTALS 

1  43OOC.O0 

1  17500.00 

41  % 

1  14333.33 

14136.36 

99  % 

**  Indle«t«a  an  ovaraxpandltuxa  ot  tMnda . 

Figure  29.  Monthly  Budget  Expenditure  Report 

6  Flag  Field.  This  field  prints  a  "**"  if  the  amount  fqjent  for  the  quarter  or 
month  exceeds  the  amount  allocated  for  the  quarter  or  month  (see  Note  8  below). 
This  flag  serves  as  a  visual  indicator  to  the  reader  and  highlights  probable 
problem  areas. 


7  Percent  Spent  for  Quarter.  This  field  is  computed  by  dividing  the  amount 
expended  so  far  in  the  quarter  (as  determined  in  Note  5  above)  by  the  allocation 
ter  the  quarter. 

8  Funds  per  Month.  This  amount  is  computed  by  dividing  the  quarterly 
allocations  by  three  to  provide  monthly  allocations  for  the  sections. 


9  Percent  Spent  for  Month.  This  field  is  computed  hy  dividing  the  amount 
expended  during  the  month  in  question  by  the  Funds  per  Month  (explained  in 
Note  8  above). 


(2)  Quarterly  Report.  Figure  30  is  an  illustration  of  the  quarterly 
budget  expenditure  repon.  This  report  serves  as  the  Department  Chiefs  indicator  of  the 
status  of  funds  for  the  selected  quarter.  This  report,  like  the  monthly  report,  is  critical 
in  allowing  the  Department  Chief  to  monitor  the  sections’  compliance  with  the 
department’s  budget.  This  report  is  also  provided  to  the  .section  chiefs  for  the  same 


reason. 
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The  quanerly  report  is  designed  to  closely  resemble  the  monthly 
report.  This  report  remains  in  the  same  foimat  as  the  monthly  report,  but  excludes  all 
the  fields  relating  to  monthly  expenditures. 

The  user  is  prompted  to  enter  the  fiscal  year  and  the  quarter  desired 
prior  to  the  output  of  this  report.  The  fields  required  for  each  record  are  the  same  as 
described  in  Subsection  (1)  on  the  monthly  budget  expenditure  report. 


DEPAF.TMEiJT  TOTALS 


43000.00 


17500.00 


41  % 


*•  Indicates  an  overexpenditure  of  funds. 


Figure  30.  Quarterly  Budget  Report 

The  following  numbered  items,  which  clarify  the  calculated  fields 
within  the  report,  correspond  to  the  numbers  in  Figure  30. 

1  This  is  the  Fiscal  Year  of  the  report. 

2  This  is  the  quarter  of  the  report. 

3  Report  date  provided  by  the  system. 

4  Spent  for  Quarter.  This  field  is  calculated  by  summing  all  the  monthly 
expenditures  for  the  requested  quaner.  For  instance,  the  system  searches  the 
monthly  expenditure  database  and  finds  all  expenditures  for  the  selected  quarter’s 
months,  for  each  APC. 
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5  Flag  Field.  This  field  prints  a  if  the  amount  spent  for  the  quarter  exceeds 
the  amount  allocated  for  the  quarter.  This  flag  serves  as  a  visual  indicator  to  the 
reader  and  highlights  probable  problem  areas. 


6  Percent  Spent  for  Quarter.  This  field  is  computed  by  dividing  the  amount 
expended  so  far  in  the  quarter  (as  described  in  Note  4  above)  by  the  allocation 
for  the  quarter.  This  process  is  repeated  for  each  APC. 

(3)  Fiscal  Year  Allocation  Report.  Figure  31  is  a  representation  of 

the  Fiscal  Year  Allocation  Report.  TTiis  report  shows  the  allocation  for  each  APC  for 


eadi  quarter  in  the  user  selected  fiscal  year.  This  report  also  shows  the  percent  change 


between  the  previous  fiscal  year’s  allocation  and  the  selected  fiscal  year’s  allocation. 


This  report  provides  the  Chief  with  a  quick  look  at  the  relative  allocations  for  each  of 


his  sections  compared  with  fund  allocations  from  the  previous  fiscal  year. 

FISCAL  YEAR  ALLOCATION  REPORT 
FY  89 


OEPAP.TMENT  Of  FAMILY  PRACTlCt  4 
COMkURiTY (TDAi 


W140  PRIMARY  CARE 
C,  FAK  PRAC 
R357  FAM  PRAC  CLINIC 
If35f  CTMS-FPC 


S16.00 
2000.00 

8000.00  -0.50 

8000.00  1.08 


518.00 

2000.00 

8000.00  -0.50 

8000.00  1.08 


518.00 

2000.00 

8000.00  -0.50 

8000.00  1.08 


2550.00 
14000.00 
38000.00  -0.40 

29000.00  1.24 


The  user  is  prompted  to  enter  the  fiscal  year  prior  to  the  output 


of  this  report.  The  fields  required  for  output  of  this  report  include: 


•  APC. 


•  Section  Description. 
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•  Allocations.  For  each  APC  for  the  current  year. 

•  Allocations.  For  each  APC  for  the  previous  year. 

The  following  numbered  items,  which  clarify  the  calculated  fields 

within  the  report,  correspond  with  the  numbers  in  Figure  31. 

1.  This  percentage  reflects  the  percent  change  between  the  previous  fiscal  year’s 
allocation  and  the  currently  selected  fiscal  year  allocation. 

2  Totals  for  the  department.  Tliis  number  reflects  the  total  allocation  for  the 
department  for  each  quarter  in  the  selected  fiscal  year.  This  figure  is  calculated 
from  totaling  all  quarter  allocations  for  all  of  the  APCs  within  the  APC 
Allocation  Database. 

3  In  the  cases  where  an  APC  did  not  exist  in  a  prior  year,  the  percentage  change 
field  (as  described  in  Note  1)  is  left  blank. 

(4)  Fiscal  Year  Recap.  Figure  32  provides  an  illustration  of  the  Fiscal 
Year  Recap  Report.  This  report  serves  as  the  Department  Chief’s  indicator  of  the  year’s 
funds  status  for  the  department.  This  report  is  critical  in  allowing  the  Department  Chief 
to  analyze  each  section’s  compliance  with  the  imposed  funds  limitations.  Throughout 


the  year,  this  report  can  provide  a  quick  look  at  the  current  status  of  funds  remaining 
to  fulfill  the  needs  for  the  rest  of  the  fiscal  year. 


Oopartmont  of  family  Practic* 
FISCAL  YEAR  RECAP  REPORT 

Fiscal  Yaar  :  99 

Raport  Data  :  7/20/89 

APC  INFORMATION 

FISCAL  YEAP 

89 

RECAP 

APC 

SECTION 

ALLOCATED 

SPENT 

8 

PERCENT 

SPENT 

UNDER  COMMITTED 
THIS  FY 

OVER  COMMITTED 
THIS  FY 

iri40 

PRIMARY  CARE 

16419.00 

1091.43 

6  % 

15532-57 

**  Zndic«t«9  art  ovaraxpandltur*  of  funds. 


Figure  32.  Fiscal  Year  Recap  Report 
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The  user  is  prompted  to  enter  the  fiscal  year  desired  prior  to  the 
output  of  this  report.  The  fields  required  for  output  of  this  report  include; 

•  APC. 

•  Section  description. 

•  Allocation  for  the  quarter. 

•  Expenditure  for  the  month. 

The  following  numbered  items,  which  clarify  the  calculated  Eelds 

within  die  report,  correspond  with  the  numbers  in  Figure  32. 

1.  Allocated  Funds  for  FY.  This  number  represents  the  allocation  for  each  APC 
in  the  allocation  database  for  the  selected  fiscal  year.  This  number  is  computed 
by  totaling  all  quarter’s  allocations  within  the  selected  fiscal  year  for  each  APC. 

2  Total  Spent  this  FY.  This  represents  the  total  amount  spent  in  the  selected 
fiscal  year  for  the  APC  .  This  number  represents  a  total  of  all  monthly 
expenditures  for  the  selected  fiscal  year  in  the  monthly  expenditure  database. 

3  Uncommitted  Funds  this  FY.  This  number  represents  the  difference  between 
located  Funds  for  FY  (Note  i)  and  Total  Spent  FY  (Note  2). 

4  Over  Committed  this  Fiscal  Year.  This  column  is  printed  when  the 
imcommitted  funds  are  negative  in  the  preceeding  column  (Note  3).  It  serves  to 
flag  overcommited  sections  within  the  department. 

5  Percent  Spent  FY  .  This  column  is  calculated  by  dividing  the  Total  Spent  this 
FY  figure  (Note  2)  by  the  Allocated  Funds  for  FY  figure  (Note  1.). 

6  Department  Totals.  These  numbers,  with  the  exception  of  Percent  Spent  (Note 

are  totals  of  the  respective  column  above  the  numbers.  The  Percent  Spent 
figure  is  the  total  spent  for  the  fiscal  year  divided  by  the  total  allocated  funds. 

(5)  Percent  Spent  For  (garter  Graph  (see  Figure  33).  This  report 

provides  the  Department  Chief  with  a  graphical  portrayal  of  the  funds  remaining  for 

each  APC  for  a  selected  quarter.  This  graph  provides  a  visual  picture  of  the  current 

status  of  aU  of  the  APC’s  expenditures. 
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Department  of  Family  Practice 

Percent  Spent  for  Quarter 


APC  SECTION 

PRIMARY  CARE 
FAM  PRAC  CL 
CTMC-FPC 
EMS 
FSO 
QOC 
POM-HC 
CTMC 
BN  AID  STATION 
FHL-HC 
CTMC  (WkTH) 
CTMC  (RAO) 
CTMC  (PHARM) 
AMB  SVC 
CTMC  (IMMUN) 
BN  AID  STAT  (IMMUN) 
DEPARTMENT 


140% 


1 


0%  20%  40%  e0%  80%  100%  120%  140% 


PERCENT  SPENT 


Figure  33.  Percent  Spent  for  Quaiter  Graph 


The  user  is  prompted  to  enter  the  fiscal  year  and  quarter  desired 


prior  to  output  of  this  report.  This  report  requires  the  following  fields  to  be  completed; 


•  APC. 

•  Section  description. 

•  Total  Expenditures  for  the  quarter  for  each  APC 

•  Allocation  for  the  quarter  for  each  APC  . 

The  following  numbered  items  correspond  to  the  numbered  items 


in  Figure  33: 

1  The  X-axis  represents  the  APC’s  expenditures  for  the  quarter  on  a  scale  from 
0  to  100  percent  of  the  amount  allocated  for  the  section. 


no 


2  The  actual  computation  of  this  percentage  conies  from  dividing  the  total 
expenditures  for  a  section  by  the  allocation  for  that  section. 

3  APC’s  active  in  the  selected  quarter  are  reported  along  the  Y-axis, 

(6)  Trend  Analysis  Grtqih  (see  Figure  34).  These  two  grtqihical  pictures 
provide  the  Chief  with  a  look  at  the  current  trend  in  expenditures  for  the  current  year 
and  the  trends  for  the  two  previous  years.  The  expenditures  are  compared  to  the 
allocations  for  the  respective  fiscal  years.  This  report  will  be  used  to  report  and  track 
the  overall  budgetary  trends  within  the  department  for  the  current  fiscal  year.  This 
report  can  be  called  up  at  any  time  during  the  current  fiscal  year. 

The  user  is  required  to  enter  the  fiscal  year  prior  to  output  of  this 
report.  The  data  fields  necessary  to  create  this  report  include: 

•  Total  Allocation  for  all  APCs  for  each  quaner  within  the  selected  fiscal  year. 

•  Total  expenditures  for  all  APCs  for  each  month  within  the  selected  fiscal  year. 
This  will  not  be  graphed  but  serves  as  the  building  block  for  the  gr^hing  of 
this  data  on  a  cumulative  basis. 

A  calculated  cumulative  total  for  each  of  the  above  data  fields  is 
required  to  create  these  two  graphs.  As  depicted  in  Figure  34,  one  line  is  graphed  to 
represent  the  cumulative  total  of  each  quarter’s  allocation.  The  second  line  represents 
the  ciunulative  total  expenditures  for  each  month. 

The  following  numbered  items  correspond  with  Figure  34. 

1  This  Line  reflects  the  cumulative  total  for  the  total  allocations  for  all  APC’s 
reported  for  the  selected  fiscal  year  in  die  APC  Allocation  Database. 

2  Each  tick  mark  on  the  line  corresponds  to  the  actual  total  expenditure  for  all 
APCs  for  the  given  month  on  the  X  axis. 


Ill 


Department  of  Family  Practice 


3  This  graph  represents  a  long  term  trend  analysis  of  department  wide 
expenditures.  The  system  uses  the  current  fiscal  year’s  expenditures  and  the  two 
previous  year’s  expenditures  to  create  this  graph 

4  The  fiscal  year  of  the  information  gr^hed. 

5  Quarter  allocations  are  plotted  on  the  FY  graph  by  dividing  the  quarterly 
allocation  into  three  equal  monthly  allocations  (done  within  the  department). 
These  monthly  allocations  are  then  graphed  on  a  cumulative  basis. 

6  The  percent  of  allocation  is  computed  by  dividing  the  expenditures  for  the 
month  by  the  allocation  for  the  month. 

2.  Equipment  Information  System  (see  Program,  Appendix  D) 

Figure  35  is  the  UCD  describing  the  proposed  Equipment  Information 
System.  As  shown  in  the  diagram,  initial  equipment  requirements  are  identified  with 
the  department’s  Resource  Information  Report  (RIR).  'The  RIR  is  shown  in  Figure  36. 
This  report  is  completed  by  the  sections  and  submitted  to  the  department  NCOIC.  In 
addition  to  new  equipment  requirements,  the  RIR  is  also  the  medium  for  updating 
previously  submitted  equqjment  requirements.  The  information  contained  in  the  RIR 
is  used  by  the  department  to  update  the  equipment  procurement  database.  As  shown 
in  Figure  36,  the  RIR  is  also  the  medium  for  collecting  section  personnel  information, 
i.e.,  gains,  losses,  and  changes.  The  personnel  portion  of  the  RIR  is  discussed  in 
Section  3,  Personnel  System. 
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Figure  35.  Equipment  Information  System  User  Concept  Diagram 
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DIPABTHINT  OP  PAMILT  PRACTtCt  AND  COHHUHITT  HIDICINB 

mSOUPCB  INPORHATION  MPORT  (RIR)  b.  Naw  Iqulpaant  Raqulraaanta 


a.  Data  Structures 


The  Equ^ment  System  consists  of  two  databases.  The  primary  database 
maintains  the  active  department  equipment  requirements  and  contains  the  following  data 
fields: 

•  Equ^ment  Code  Number.  This  number,  assigned  by  the  system,  uniquely 
identifies  each  equipment  item  in  the  database. 

•  Section  Code.  Explained  in  Section  1,  Budget  System. 

•  Date  of  Request.  The  date  equipment  is  requested  by  the  section. 

•  Item  Description.  This  is  a  short  description  of  each  equipment  item  identiried 
in  the  database. 

•  Type  of  Request.  The  equipment  requested  will  be  one  of  four  types, 
MEDCASE,  CEEP,  CAPR,  or  other  as  described  in  Ch^ter  IV. 

•  Priority.  The  priority  number  is  a  ranking  of  all  of  the  equipment  to  indicate 
the  relative  priority  of  each.  The  Department  Chief  assigns  the  priority  to  all 
department  equipment  using  the  priority  worksheet  described  in  the  Outputs 
section  below. 

•  Urgency  Code.  The  urgency  code  indicates  how  soon  the  equipment  is  needed 
by  the  section. 

•  Quantity. 

•  Unit  Price. 

•  Extended  Price.  Quantity  *  Unit  Price. 

•  Status  of  Procurement.  The  status  of  the  procurement  is  indicated  by  one  of 
five  codes  to  show  where  each  equipment  request  is  in  the  procurement 
process.  The  five  codes  and  their  meaning  are  listed  below: 

PW  Paperwork  is  being  prepared  by  the  section  requesting  the  equipment. 
RM  RMD  is  processing  the  equipment  request. 

AP  RMD  has  approved  the  equipment  procurement. 

OO  The  section  as  put  the  equipment  on  order. 

RC  The  equipment  has  been  received  by  the  section. 

•  Comments. 
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The  second  database  maintains  the  historical  infonnation  on  equipment 
previously  procured  by  the  department  and  consists  of  the  following  data  Helds: 

•  Section  Code. 

•  Item  Description. 

•  Type  of  Request. 

•  Quantity. 

•  Extended  Price. 

'  A 

•  Date  of  Request.  Taken  from  primary  database  described  above. 

•  Transfer  Date.  The  date  the  item  was  transferred  to  the  historical  database 
(upon  receipt  of  the  equipment). 

•  Months  to  Complete  Procurement.  The  difference  between  the  date  of  request 
and  the  transfer  date. 

•  Comments. 

b.  Data  Inputs 

The  Equipment  System  menu  hierarchy  chart  is  shown  in  Figure  37. 
The  menu  system  allows  the  user  to  update  the  equipment  database,  print  reports,  and 
archive  completed  equipment  procurements  in  the  historical  database.  Users  enter  new 
equipment  requirements  into  the  primary  equipment  database  using  the  input  screen 
shown  in  Figure  38.  This  screen  presents  all  of  the  data  Helds  necessary  for  user  input 
and  displays  the  various  codes  needed  for  the  speciHc  data  fields. 

To  change  or  remove  equipment  from  the  database,  the  user  selects  the 
appropriate  menu  item  and  is  then  prompted  to  enter  the  equipment  code  number  or 
the  section  code  to  identify  the  equipment  to  be  changed  or  removed.  If  the  user  does 
not  know  the  equipment  code  number,  he  or  she  can  enter  the  section  code.  A  list 


EQUIPMENT  SYSTEM 
Section  1 


Section  2 


Figure  37.  Equipment  Menu  Tree 


of  all  equipment  requirements  for  that  section  is  presented.  The  user  is  then  asked  to 
enter  the  record  number  (displayed  to  the  left  of  each  equipment  item)  of  the  desired 
equqnnent  record  to  change.  When  changing  equipment  data,  the  user  is  presented 
with  the  same  screen  discussed  above  for  new  data  entry. 


Figure  38.  Equipment  Input  Screen 

The  user  is  allowed  to  update  the  priorities  on  the  equipment  list. 
Priority  changes  are  obtained  from  the  priority  worksheet  (discussed  in  the  Output 
section  below).  The  Department  Chief  reviews  all  equipment  requests  and  completes 
the  priority  worksheet  to  identify  overall  department  priorities.  The  database  is  then 
updated  with  die  new  priorities.  After  selecting  the  equipment,  the  user  is  presented 
with  a  review  screen  similar  to  that  described  in  Section  C  of  this  charter.  The  fields 
di^layed  correspond  to  the  priority  worksheet  to  simplify  user  input  and  are  listed 
below: 


Equipment  Code  Number. 
Type  of  Request. 

Section  Code. 
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•  Item  Description. 

•  Urgency  Code. 

•  Priority.  The  Department  ChiePs  numerical  ranking  for  the  item. 

•  Quantity. 

•  Unit  Price. 

The  user  is  allowed  to  enter  the  changes  directly  to  the  review  screen. 
When  equipment  status  changes,  e.g.,  an  equipment  requisition  is  submitted  or 
equipment  is  received,  the  sections  are  required  to  indicate  this  on  the  RIR  and  submit 
it  to  the  department  NCOIC.  These  status  changes  are  then  entered  into  the  database 
using  the  input  screen  shown  in  Figure  39.  This  screen  is  similar  in  format  to  the 
Status  Update  section  on  the  RIR  to  simplify  user  data  entry. 


1  SECTION  FPC  1 

EQUIP  CODE 

ITEM  DESCRIPTION  QTY 

UNIT  PRICE 

STATUS 

9010.01 

BREAST  PUMP  2 

1300.00 

PW 

Press  ESC  to  abort  editing,  ENTER  to  complete  changes. 


Figure  39.  Status  Update  Screen 
c.  Outputs 

(1)  Review  Equipment  List.  The  format  of  the  review  screen  is 
discussed  in  Section  B  above.  All  of  the  equipment  database  fields  are  listed  on  the 
review  output  screen.  The  user  can  scroll  left  and  right,  up  and  down,  to  view  or 
change  all  fields  for  each  record. 
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(2)  Dqjartment  Equipment  Report  (sec  Figure  40).  The  department 
equipment  report  is  a  complete  equipment  requirements  listing  for  the  department.  All 
of  the  fields  in  the  equipment  database  are  used  to  produce  this  report.  The  user  is 
allowed  to  choose  one  of  three  sort  options.  The  flexibility  to  select  the  sort  option 
makes  it  easier  to  highlight  those  aspects  of  equipment  procurement  most  important  to 


the  Department  Chief.  Each  sort  option  is  discussed  below: 


•  Sotting  by  Cost.  The  equipment  list  is  sorted  by  the  extended  price  field, 
from  high  values  to  low. 

•  Sorting  by  Urgency.  The  equipment  list  is  sorted  by  the  urgency  code,  from 
zero  (0)  for  immediate  equipment  requirements  to  four  (4)  for  non-urgent 
requirements.  Within  each  urgency  code  section  the  equipment  is  further 
sorted  by  section  code  and  extended  price  (from  high  to  low). 


•  Sorting  by  Status.  The  status  sort  option  groups  the  equipment  information 
by  each  of  the  five  status  codes.  Each  group  is  further  sotted  by  section  code 
and  extended  price  (from  high  to  low). 


TTPE  50RTt  COST 


roWARTKEKT  EQOIPMBMT  REPORT 


lATE!  7/20/89 


eq 

RCQ 

TYPE 

DNIT 

EXTENDED 

ACCDMOLATED 

CODE 

SECT 

DATE 

DESCRIPTION 

REO 

PRI 

me 

QTY 

PRICE 

PRICE 

TOTALS  STAT 

COMMENTS 

*010.01 

rpc 

01/10/89  BEDPMI 

KEDC 

2 

X 

2 

5200.00 

10400.00 

10400.00 

PW 

9025.20 

EHS 

01/20/89  SPIT  COP 

OTBE 

5 

2 

5 

1000.00 

5000.00 

15400.00 

00 

BACKORD 

0360.89 

CTH 

12/15/88  MICROCOHPOTER 

CAPR 

9 

1 

1 

3000.00 

3000.00 

10400.00 

00 

BACKORD 

9100.60 

CTP 

04/10/89  GAMMA  CAMERA 

CEEP 

4 

1 

I 

1000.00 

1000.00 

19400.00 

AP 

@ 


Figure  40.  Department  Equipment  Report 


The  following  numbered  items  correspond  to  the  numbers  in  Figure 


40  and  explain  certain  portions  of  the  report. 

1  The  system  date  is  printed  at  die  top  of  the  report. 

2  The  type  of  sort  indicates  how  the  equipment  list  has  been  sorted,  by  COST, 
URGENCY,  or  STATUS. 

3  The  format  of  the  fields  listed  across  the  top  remains  the  same  regardless  of 
the  sort  cation  chosen. 
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4  The  cumulative  total  is  calculated  by  adding  each  successive  extended  price  to 
the  previous  cumulative  total. 


(3)  Equipment  Type  Report  (see  Figure  41).  The  equipment  type 


report  is  a  listing  of  the  equipment  requirements  for  one  of  the  equipment  types,  either 


MEDCASE,  CEEP,  CAPR,  or  OTHER.  The  user  selects  the  type  of  equipment  he  or 
she  wants  listed  from  the  menu.  All  of  the  fields  in  the  equipment  database  are  used 
to  produce  this  report.  The  user  is  allowed  to  choose  one  of  two  sort  options.  Each 
sort  option  is  discussed  below: 

•  Sorting  by  Cost.  The  equipment  list  is  sorted  by  the  extended  price  field, 
from  high  values  to  low. 


•  Sorting  by  Priority.  The  equipment  list  is  sorted  by  the  priority  code,  from 
one  for  highest  priority  to  the  lowest  existing  priority  in  the  database.  Within 
each  priority  section  the  equipment  is  further  sorted  by  section  code  and 
extended  price  (from  high  to  low). 


TYPE  EQUIPMENT 
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Figure  41.  Equipment  Type  Report 


The  following  numbered  items  correspond  to  the  numbers  in  Figure 


41  and  explain  certain  portions  of  the  report. 


I  The  system  date  is  printed  at  the  top  of  the  report. 


2  The  type  of  equipment  indicates  which  equipment  type  is  listed  in  the  report, 
either  MEDCASE,  CEEP,  CAPR.  or  OTHER. 


3  The  format  of  the  fields  listed  across  the  top  remains  the  same  regardless  of 
the  sort  option  chosen. 


4  The  cumulative  total  is  calculated  by  adding  each  successive  extended  price  to 
the  previous  cumulative  total. 
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(4)  Equipment  Priority  Worksheet  (see  Figure  42).  The  priority 
woiksheet  is  used  by  the  Department  Chief  in  a  meeting  with  each  of  his  section 
chiefs.  In  this  meeting,  the  priority  of  all  of  the  department’s  equipment  requirements 
is  determined  and  aimotated  on  the  priority  woricsheets  for  each  equipment  type.  These 


worksheets  are  then  used  to  update  the  priorities  in  the  equipment  database. 
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Figure  42.  Equipment  Priority  Worksheet 


The  data  fields  necessary  to  produce  the  priority  worksheet  are 


listed  below: 


•  Type  of  Equipment. 

•  Equipment  Code  Number. 

•  Section  Code. 

•  Item  Description. 

•  Priority. 

•  Urgency  Code. 

•  Quantity. 

•  Unit  Price. 

•  Extended  Price. 

•  Comments. 


The  following  numbered  items  correspond  to  the  numbers  in 


Figure  42  and  explain  certain  portions  of  the  report. 
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1  The  system  date  is  printed  at  die  top  of  the  report. 

2  The  type  of  equipment  indicates  which  equipment  type  is  listed  in  the  report, 
either  MEDCASE,  CEEP,  CAPR,  or  OTHER. 

3  A  fill  in  section  is  provided  to  allow  the  Department  Chief  to  enter  the  updated 
priorities. 


(5)  Equipment  Historical  Report  (see  Figure  43).  Once  equipment 
is  received,  the  data  referencing  it  can  be  archived  from  the  primary  equipment 
database  to  the  historical  database.  All  of  the  historical  database  fields  are  used  to 
produce  the  equipment  historical  report.  The  report  can  be  sorted  either  by  section  or 


by  equipment  type.  Within  each  of  these  sort  options  the  list  is  further  sorted  by  the 
extended  price  field,  from  high  to  low. 
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4 
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Figure  43.  Equipment  Historical  Report 

The  following  numbered  items  correspond  to  the  numbers  in 
Figure  43  to  explain  the  report  information. 

1  The  transfer  date  is  automatically  entered  into  the  database  using  the  system 
date  when  the  data  is  archived. 

2  The  months  to  complete  the  procurement  are  calculated  by  subtracting  the 
transfer  date  from  the  original  request  date. 

3  Subtotals  for  each  section  or  equipment  type  group  are  shown  for  the  extended 
price  field  and  is  obtained  by  totaling  the  extended  prices  for  the  respective 
group. 
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(6)  Historical  Summary  Report  (see  Figure  44).  The  historical 
sommary  report  displays  summary  statistical  information  about  the  data  in  the  historical 
database.  The  Department  Chief  can  use  the  summary  report  to  determine  the 
department’s  history  of  equipment  procurement  in  terms  of  the  number  of  equipment 
requests,  average  costs  of  the  equipment  requested,  the  type  of  equ^ment  requested, 
and  the  average  length  of  time  to  obtain  equipment.  The  historical  database  fields 
necessary  to  create  the  summary  report  are  listed  below. 

•  Section  Code. 

•  Type  of  Request. 

•  Quantity. 

•  Extended  Price. 

•  Date  of  Request. 

•  Transfer  Date. 

•  Months  to  Complete  Procurement. 

The  following  numbered  items  correspond  to  the  numbers  in 
Figure  44  and  explain  the  method  used  to  produce  the  summary  report  information. 

1  The  earliest  date  of  request  and  the  latest  date  of  request  contained  in  the 
database  are  listed  at  the  top  of  the  report. 

2  The  total  number  of  requests  for  each  type  of  equipment  are  calculated  by 
adding  the  total  quantities  of  equipment  procured  for  each  equipment  type. 

3  The  average  cost  of  each  equipment  type  is  calculated  by  dividing  the  total 
extended  price  for  the  equipment  type  group  by  the  total  number  of  requests  for 
that  equipment  type  group. 

4  The  average  time  to  complete  an  equipment  procurement  is  calculated  by 
averaging  all  of  the  figures  for  the  number  of  months  to  complete  each 
procurement  for  each  equipment  type. 
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5  The  total  number  of  requests  for  each  type  of  equipment  is  summed  for  each 
section. 

6  The  average  cost  for  each  type  of  equ^ment  is  calculated  for  each  section  by 
dividing  the  total  cost  of  the  equipment  type  requests  for  a  section  by  the  total 
number  of  requests  for  that  equipment  type  for  the  section. 


HISTORICAL  St»®lARY  REPORT 


requests  by  type 

EARLIEST  REO  DATE:  1/13/88 
LATEST  REQ  DATE:  7/20/89 

TYPE  REQUEST 
CAPR 

MEDC 

CEEP 

«  REQUESTS 

(Da 

AVG'TiOST 

7500.00 

3500.00 

11000.00 

AVG  MONTHS 

TO  COMPLETE 

3.1 

2.5 

4.7 

«  REQUESTS  BY  SECTION 

SECTION 

FPC 

CTM 

GOC  \3/ 

EMS 

•  MEOCASE 

25 

14 

1 

1 

«  CEEP 

13 

11 

2 

0 

4  CAPR 

7 

6 

0 

0 

«  OTHER 

10 

5 

2 

3 

AVERAGE  COST  BY  SECTION 

SECTION 

FPC 

S  (g) 

EMS 

AVG  MEDCASE 
4400.00 
3700.00 
3400.00 
3000.00 

AVG  CEEP 
13000.00 
9000.00 
6500.00 
0.00 

AVG  CAPR 
8500.00 
3400.00 
0.00 
0.00 

AVG  OTHER 
2900.00 
3000.00 
2700.00 
2650.00 

Figure  44.  Historical  Summary  Report 


3.  Personnel  Information  System  (.see  Program,  Appendix  E) 


Figure  45  is  the  user  concept  diagram  for  the  personnel  information  system. 


This  system  interfaces  the  four  major  persomiel  subsystems  identified  in  Chapter  FV. 


These  information  subsystems  include. 

•  Department  Personnel  Information  Subsystem  (including  personal  data). 

•  Table  of  Distribution  and  Allowances  Subsystem. 

•  Leave  and  Absence  Recordkeeping  Subsystem. 

•  Continuing  Medical  Education  (CME)  Budget  Subsystem. 
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Figure  45.  Pereonnel  Information  System  User  Concept  Diagram 
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The  consolidation  of  all  four  personnel  subsystems  under  one  major  system 
simpliHes  the  transfer  and  maintenance  of  the  six  data  files  necessary  to  maintain  the 
data.  All  persoimel  inputs,  processing,  and  outputs  are  captured  within  a  single  series 


of  operations  without  requiring  the  user  to  leave  the  current  application  environment. 
a.  Data  Structures 

Figure  46  depicts  the  various  database  files  required  to  support  the 
personnel  information  system.  This  figure  shows  how  the  file  that  represents  a  person 
within  the  department  serves  as  the  pivotal  point  for  the  interrelation  of  all  of  the 
personnel  files. 


PERSOKNtL  DATABASE 


Figure  46.  Personnel  Data  Structures 
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The  key  field  identified  throughout  the  database  is  the  Personnel 
Identification  Code  as  described  below.  This  code  is  already  used  in  the  current  system. 
It  is  recognized  as  the  method  by  which  personnel  data  should  be  ntaintained 
throughout  the  department. 

The  personnel  file,  which  represents  an  individual  assigned  to  the 
department,  contains  the  following  fields: 

•  Personnel  Identification  Code.  This  code  is  derived  from  the  first  letter  of  an 
individual’s  last  name,  combined  with  the  last  four  numbers  of  their  social 
security  number. 

•  Last  Name. 

•  First  Name  and  Middle  Initial. 

•  Rank. 

•  Branch  of  Service  (accepted  military  abbreviations  e.g..  Medical  Corps  (MC), 
Army  Nurse  Corps  (AN),  etc.). 

•  Military  Occupational  Specialty  Code. 

•  Arrival  Date  within  the  Department. 

•  Anticipated  Date  of  PCS  (if  known). 

•  Currently  assigned  TDA  Paragraph  Number. 

•  Currently  assigned  TDA  Line  Number. 

•  Currently  assigned  TDA  Position  Number.  If  the  person  is  carried  as  excess, 
this  number  will  be  99. 

•  Doctor  Status  (if  appropriate).  This  code  serves  to  track  only  the  current 
training  status  of  doctors  in  the  residency  program.  The  codes  used  are;  (1) 
Third  Year  Residency,  (2)  Second  Year  Residency,  (3)  First  Year  Residency 
(Student). 
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The  personal  information  database  file  serves  as  the  repository  of 
sensitive  information  about  an  assigned  individual.  Each  record  contains: 

•  Personnel  Identification  Code.  This  code  serves  to  relate  this  file  to  the 
personnel  file. 

•  Local  Home  address. 

•  City  of  Home  address. 

•  State. 

•  Spouse’s  first  name  (if  s^ropriate). 

•  Children’s  names,  followed  by  their  ages  (if  appropriate). 

•  Home  telephone  number. 

•  Date  of  rank. 

•  Personal  Comments. 

The  Table  of  Distributions  and  Allowances  (TDA)  database  file  reflects 
the  current  positions  available  as  obtained  from  the  most  up  to  date  TDA  for  the 
department.  Each  record  contains  the  following  fields: 

•  TDA  Paragraph  Number. 

•  TDA  Line  Number. 

•  TDA  Position  Number. 

•  TDA  Official  Job  Tide. 

•  The  APC  that  relates  to  this  particular  position. 

•  The  authorized  branch  of  service  of  this  position. 

•  The  authorized  rank  or  grade  for  this  position. 

•  The  authorized  Military  Occupational  Specialty  for  this  position. 
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•  Authorized  field.  This  field  is  used  to  deteimine  if  the  position  is  an 
authorized  position  under  the  current  TDA.  This  position  could  actually  be 
required  under  the  TDA  but  not  authorized  under  peacetime  conditions.  This 
is  a  common  occurrence  in  TDAs  in  the  military. 

The  Continuing  Medical  Education  funds  allocation  database  records  the 
CME  allocation  for  each  fiiscal  year.  Each  record  contains  the  following  fields: 

•  Fiscal  Year. 

•  Allocation  for  the  fiscal  year  in  dollars. 

The  Continuing  Medical  Education  request  database  records  the  doctors’ 
requests  for  CME  funded  education.  Each  doctor  can  have  several  active  CME  requests 
within  this  database.  Each  record  contains  the  following  fields: 

•  Personnel  Identification  Code. 

•  Fiscal  Year  of  the  request. 

•  Type  Request.  The  CME  request  can  be  one  of  the  following  types  of 
requests:  (C)  Conference/Meeting  Travel,  (G)  General  Mission  Travel,  (B) 
Board  Certification. 

•  Start  Date  of  Travel. 

•  End  Date  of  Travel. 

•  Duration  of  travel.  This  field  is  computed  by  determining  the  number  of  days 
between  the  start  date  and  the  end  date.  -liiis  data  is  used  in  the  statistical 
summary  reports  described  in  Section  3.c,  Outputs,  below. 

•  Location  or  Destination. 

•  Puipose  of  travel.  The  title  of  the  conference  or  the  specific  purpose  of  the 
request. 

•  Travel  Mode.  Travel  can  either  be  by  (A)  aircraft,  (P)  privately  owned  vehicle, 
or  (G)  government  provided  groimd  transportation.  This  is  used  in  the 
computation  of  the  costs  involved  in  the  travel. 
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•  Travel  cost  (Actual  or  estimated  cost  depending  on  the  Costing  Code  described 
below). 

•  Per  Diem  Cost  (Actual  or  estimated  cost  depending  on  the  dusting  Code 
described  below). 

•  Registration  Fee  for  the  Conference  (Actual  or  estimated  cost  depending  on 
Costing  Code  described  below). 

•  Reimbursable  expenses  (Actual  or  estimated  cost  depending  on  Costing  Code 
described  below). 

•  Total  Cost  of  travel.  This  field  is  calculated  by  adding  the  Travel  cost,  Per 
Diem  cost,  Registration  Fee,  and  Reimbursable  expenses  fields  (Actual  or 
estimated  total  cost  depending  on  the  Costing  Code  of  the  related  fields). 

•  Costing  Code.  This  code  differentiates  between  an  estimated  total  cost  and  the 
actual  costs.  The  actual  costs  are  identified  once  the  travel  has  been  completed 
and  the  travel  claim  voucher  is  received  by  the  department. 

The  Absence  database  maintains  the  record  of  all  requested  leaves  or 
other  absences,  e.g.,  permissive  TDY,  emergency  leave.  This  database  does  not  record 
the  CME  requests  discussed  in  the  CME  request  database  section.  Each  record  contains 
the  following  fields: 

•  Personnel  Identification  Code. 

•  Fiscal  Year  of  request. 

•  Type  of  request.  (L)  Ordinary  Leave,  (P)  Permissive  TDY,  (E)  Emergency 
Leave,  (S)  Sick  Leave  or  Convalescence  leave,  (T)  Temporary  Duty,  or  (O) 
other  type  of  unspecified  absences. 

•  Start  Date  of  Absence. 

•  End  Date  of  Absence. 

•  Duration  of  absence.  This  field  is  computed  by  determining  the  number  of 
days  between  the  start  date  and  the  end  date. 

•  Conunents  on  special  circumstances. 
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b.  Data  Inputs 

The  Personnel  Infonnation  System  menu  hierarchy  chart  is  shown  in 
Figure  47.  This  menu  system  allows  die  user  to  update  the  persoimel  system  databases 
in  the  following  areas: 

•  Add,  change  oi  remove  records  in  the  persoimel  and  personal  database. 

•  Add,  change  or  remove  records  in  the  Table  of  Distributions  and  Allowances 
database. 

•  Update  the  Persoimel  Files  from  information  provided  on  the  Resource 
Information  Report  explained  in  the  equipment  information  system  Section  (2). 

•  Add,  change,  or  remove  records  in  the  Continuing  Medical  Education  request 
and  funds  allocation  databases.  The  user  can  also  print  the  two  required  reports 
for  CME  fund  monitoring. 

•  Add,  change  or  remove  records  from  the  absence  database. 

The  following  sections  describe  the  major  data  entry  requirements  for 
the  personnel  system.  The  common  data  entry  requirements  are  described  in  the  first 
section.  This  descr^tion  is  followed  by  the  data  input  requirements  for  each  of  the 
major  input  submenus  depicted  in  Figure  47. 

(1)  Common  Input  Requirements.  In  most  of  the  submenus,  the  user 
is  required  to  enter  a  personnel  identification  code  (PIC).  The  standardized  entry  screen 
discussed  in  Section  C.2.a,  Input  Screens,  is  used  for  this  input.  The  system  then 
verifies  the  PIC  entered  against  the  personnel  file.  If  die  PIC  is  found  in  the  database, 
the  user  is  presented  with  the  following  confirmation  screen. 
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Figure  47.  Personnel  System  Menu  Hierarchy  Chart 
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*1  cut  RtOUtSI 


THIS  IS  THE  PERSON  WHOSE  ID  CODE  IS  MHI 
LAST  NAME  FIRST  NAME  ■■■■■  RANK  ■ 

OCCUPYING  TDA  PARAGRAPH  ■§,  LINE  ■,  POSITION  ■ 
<<<<<<<<SYSTEM  MESSAGE  DEPENDING  ON  TYPE  OF  REQUEST»»»» 


This  confirmation  screen  allows  the  user  to  determine  if  the 

requested  PIC  is  correct.  This  type  of  confirmation  prevents  the  user  from  entering  a 

wrong  or  inq>propriate  PIC  that  would  destroy  the  integrity  of  the  database.  If  the 

identification  code  is  not  found,  a  warning,  "ID  Code  not  found!  Press  return  to 

continue...",  is  displayed.  The  system  then  gives  the  user  the  option  to  search  for  a  PIC 

by  entering  the  last  name  of  the  person.  All  records  with  the  requested  last  name  are 

displayed  as  shown  below  and  the  user  is  allowed  to  pick  the  identification  code  of  the 

correct  person  from  the  list. 

LAST  NAMEFIRST  NAME  ID  CODE 
SMITH  JOHN  E.  S2356 

SMITH  BECKY  K.  S9999 

ENTER  THE  ID  CODE  OF  THE  PERSON  DESIRED:  ■■ 

An  appropriate  modification  to  this  screen,  if  supported  in  the 
plication  program,  would  be  the  ability  to  select  a  record  by  highlighting  the  record 
desired  and  pressing  the  return  key.  This  process  would  eliminate  the  possibility  of 
keying  errors  being  introduced  by  the  user. 

If  the  user  is  requested  to  enter  information  on  a  TDA  position, 
the  screen  shown  below  is  presented  to  the  user. 
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WHAT  POSITION  WILL  THIS  PERSON  OCCUPY 
OR  ENTER  A  ZERO  (0)  TO  QUIT 

TDA  Paragraph  Number  imi 

TDA  Line  Number  HI 

TDA  Position  Number  H 

Another  feature  that  would  enhance  this  input  would  be  the  addition 
of  the  ability  to  call  up  all  TDA  positions  that  are  tmoccupied.  The  user  would  then 
be  allowed  to  select  a  TDA  position  by  highlighting  a  particular  position  from  among 
those  depicted  on  the  screen.  This  enhancement  will  make  the  following  two  screens 
unnecessary. 

The  system  then  verifies  the  requested  TDA  position  with  the  TDA 
database  and  if  the  position  is  found  to  exist  in  the  database,  the  user  is  presented  with 
the  following  standard  TDA  position  screen. 

POSITION  CHOSEN; 

Authorized  Branch  :  ■  Authorized  Grade  :  B 
Authorized  MOS  :  Authorized  Position  ;  YES 

This  screen  also  converts  the  authorized  position  field  from  its  coded  value  to  the 
correct  YES  or  NO  answer  depending  on  the  contents  of  this  field. 

In  the  cases  where  a  TDA  position  is  requested  and  is  found  to 
already  be  occupied  by  someone  else,  the  warning  screen  shown  below  is  presented  to 
the  user. 
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THE  POSITION  IS  ALREADY  OCCUPIED  BY: 

Last  Name  ;  ■■■■■■■■■■ 

First  Name  : 

Rank  ;  Bi 

The  user  is  then  given  the  following  choices. 

YOU  NOW  HAVE  THE  FOLLOWING  CHOICES: 

1.  MOVE  THE  PERSON  FOUND  IN  THE  POSITION  TO  EXCESS  (POSITION 
CODE  99)  AND  THE  PERSON  YOU  ARE  WORKING  WITH  INTO  THE 
POSITION  YOU  ORIGINALLY  REQUESTED. 

2.  PLACE  THE  PERSON  YOU  ARE  WORKING  WITH  INTO  THIS 
POSITION  AS  EXCESS  (OVERSTRENGTH,  POSITION  CODE  99). 

3.  TRY  ANOTHER  POSITION. 

ENTER  YOUR  CHOICE  (1-3)  :  | 

(2)  Enter,  change,  or  remove  personnel  from  the  personnel  database. 
As  discussed  earlier,  the  user  is  first  requested  to  enter  the  identifrcation  code  of  the 
individual  to  add,  change,  or  remove  from  the  personnel  file.  In  all  of  these  cases,  the 
system  first  checks  the  persoimel  file  for  the  requested  identifrcation  code  If  the  code 
is  already  in  use,  and  the  user  is  trying  to  enter  this  identifrcation  code  to  add  a  new 
person  to  the  personnel  frle,  the  standard  confrrmation  screen  is  displayed  with  the 
message  "ID  CODE  REQUESTED  IS  ALREADY  USED  BY  THE  PERSON  SHOWN 
ABOVE"  and  the  user  is  prompted  to  try  a  different  code.  When  the  user  is  updating 
or  removing  someone  already  in  the  personnel  file,  this  PIC  check  serves  to  confirm 
the  identifrcation  code  already  exists  in  the  frle  and  warns  the  user  if  it  is  not  found. 
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If  the  identification  code  is  not  found,  the  system  gives  the  user  the  same  options  as 
described  in  the  general  input  screens  discussed  earlier. 

UPDATE  PERSONNEL 

ID  CODE  is  NI456 


Laat  Name  _  First  Name  MI  RANK  BRANCH  MOS 


NOTE:  If  Position  Number  Is  99,  the  Individual  is  carried  as  excess 


Figure  48.  Personnel  Input  Screen  Format 

If  the  user  is  adding  or  changing  information  in  the  personnel 
database,  the  system  requests  the  new  position  before  displaying  a  blank  data  entry 
screen  format.  This  action  allows  the  system  to  verify  that  the  TDA  position  is  valid 
and  is  not  already  occupied  by  someone  else.  If  the  position  is  occupied,  the  standard 
choice  screen  as  discussed  earlier  is  displayed  and  the  user  must  choose  an  appropriate 
course  of  action.  Once  they  have  selected  a  course  of  action,  the  system  then  allows 
access  to  the  personnel  database.  The  screen  depicted  in  Figure  4g  is  the  standard  input 
screen  for  personnel  information.  This  screen  does  not  allow  the  user  to  either  change 
the  identiAcation  code  or  the  position  information,  thus  preventing  the  user  from 
circumventing  the  integrity  checks  already  accomplished  by  the  system. 

Once  the  user  has  entered  information  into  the  personnel  file,  he 
or  she  is  given  the  choice  to  enter  data  into  the  personal  file.  This  data  entry  format 


is  displayed  in  Figure  49.  This  screen  includes  the  privacy  act  statement  to  remind  the 
user  of  the  sensitive  nature  of  this  information. 

Thia  is  the  personal  information  for  ID  CODE  S7395 
PRIVACY  ACT  STATEMENT 

PRINCIPLE  PURPOSE!  To  maintain  personal  Information  on  individuals  assigned  to 
this  command  to  facilitate  counseling,  emergency  notification,  and  social 
event  information. 


WARNING:  This  Information  is  of  a  highly  sensitive  nature  and  should  not  be 
provided  to  anyone  outside  of  the  chain  of  command  without  approval. 


Figure  49.  Personal  Information  Data  Entry  Screen 

If  the  user  desires  to  delete  someone  from  the  personnel  databa.se, 
the  identification  code  entered  by  the  user  is  used  to  find  the  right  record.  The  screen 
depicted  in  Figure  48  is  displayed  with  the  message,  "IS  THIS  THE  PERSON  YOU 
WANT  TO  DELETE?  (Y/N)"  |  ",  included  on  the  screen.  This  allows  the  user  to 
confirm  the  information  about  the  person  they  desire  to  delete.  If  the  user  deletes  the 
person,  the  system  then  purges  all  the  files  in  the  personnel  system  which  have  the 
requested  identification  code.  Several  databases  are  affected;  the  personnel  database;  the 
personal  database;  the  CME  request  database;  and  the  absence  database. 

(3)  Enter,  change,  or  remove  TDA  information.  The  user  gains  access 
to  the  TDA  database  by  initially  entering  the  position  they  desire  to  add,  change  or 
remove  in  the  position  entry  format  described  earlier.  In  the  case  where  the  user  is 
adding  a  new  position,  this  information  allows  the  system  to  verify  that  the  TDA 
position  requested  does  not  already  exist  in  the  database.  If  the  user  is  modifying  an 
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already  existing  TDA  record,  this  information  is  used  to  locate  the  record  or  warn  the 
user  that  the  position  entered  does  not  exist  in  the  database. 

TABLE  or  DISTRIBUTION  AND  ALLOWANCES 

TDA  Listing 


Figure  50.  Table  of  Distribution  and  Allowances  Input  Screen 

The  system  must  determine  the  authorized  status  of  the  position. 
If  the  position  is  new  to  the  database,  the  user  is  required  to  answer  the  prompt,  "IS 
THIS  AN  AUTHORIZED  POSITION?  (Y/N)  |  ".  If  the  user  answers  yes,  the  system 
automatically  replaces  the  authorization  code  with  a  one,  otherwise  the  code  is  rq>laced 
with  a  zero.  If  the  user  is  modifying  an  already  existing  database,  the  system  uses  the 
existing  code  to  a^  the  user  if  they  desire  to  change  the  current  authorized  status  to 
the  opposite  status.  For  instance,  if  the  authorized  code  is  zero  (0)  (unauthorized),  the 
message,  "DO  YOU  WANT  TO  CHANGE  THIS  POSITION  TO  AN  AUTHORIZED 
STATUS?  (Y/N)  I  ",  is  displayed. 

If  the  user  desires  to  delete  a  position,  the  format  depicted  in 
Figure  50  is  used,  but  it  includes  a  message  to  verify  if  the  user  desires  to  delete  the 
displayed  record.  If  the  record  is  deleted,  the  system  also  checks  the  personnel  database 
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to  determine  if  someone  occupies  the  deleted  position.  If  a  matching  position  is  found 
in  the  personnel  database,  the  person’s  TDA  position  information  is  blanked  in  their 
record,  and  the  following  message  is  displayed. 


FOUND  CPT  SMITH  OCCUPYINC  THE  DELETED  POSITION! 

ID  CODE  IS  S234S  .  BE  SURE  YOU  UPDATE  THIS  PERSON’S 
TDA  POSITION  WITH  A  VALID  TDA  POSITION, 

(4)  Update  from  Resource  Information  Report.  This  menu  choice 
provides  the  user  with  the  capability  to  directly  update  the  personnel  database  with 
information  provided  in  the  Resource  Information  Report  personnel  sections.  Figure 
51  depicts  this  input  screen.  The  system  also  verifies  the  new  position  entered  to 
ensure  that  it  is  not  already  occupied,  and  if  it  is  occupied,  responds  with  the  screen 
of  choices  discussed  earlier. 


UPDATE  FROM  R.I.R.  REPORT 


B.  CHANGES  TO  CURRENT  TDA  (OTHER  THAN  LOSSES  OR  GAINS) 


OLD  POSITION 


NEW  POSITION 


PARA 


LINE 


POSN 


IDCODE 


LAST  NAME 


RANK 


PARA 


LINE 


POSN 


PRESS  ESCAPE  (ESC)  TO  QUIT 

Figure  51.  Update  from  RIR  Repon  screen. 

When  the  user  is  updating  from  the  personnel  losses  section  on 
the  RIR,  the  user  must  first  enter  the  PIC.  This  code  is  verified  in  the  maruier 
di.scussed  earlier.  TTie  system  then  prompts  the  user  with.  "HAS  TIITS  PERSON 
ACTUALLY  DEPARTED  OR  IS  THIS  AN  UPDATE  TO  A  PROJECTED  LOSS 
DATE?  (ACTUAL=0,  PROJECTED=l)  If  the  change  is  a  modification  of  the 


anticipated  loss  date,  the  user  enters  the  new  loss  date,  and  the  record  is  updated 
automatically.  If  the  loss  is  an  actual  PCS  from  the  department,  the  system  invokes  the 
same  procedures  as  described  for  the  deletion  of  personnel  in  Section  (2)  earlier. 

(S)  Enter,  change,  or  remove  CME  requests.  Figure  52  depicts  the 

standard  input  screen  for  the  CME  request.  This  screen  is  designed  to  match  the  format 

of  the  actual  printed  CME  request  form  used.  The  bottom  of  the  screen  is  used  to 

depict  whether  the  costs  displayed  are  actual  expended  costs  or  estimated  costs.  If  the 

user  desires  to  change  an  already  existing  record,  the  user  must  first  enter  the  fiscal 

year  of  the  request  and  the  PIC  code  of  the  person  sought.  As  discussed  earlier,  the 

confirmation  screen  displays  the  personnel  information  about  the  selected  PIC  with  the 

message,  "IS  TfflS  THE  PERSON  YOU  EXPECTED?  (Y/N)  |."  The  system  then 

displays  all  matching  records  in  the  following  format: 

RECORD  NO.  ID  CODE  TYPE  START  DATE  END  DATE 

5  S7777  C  06/07/89  07/07/89 

15  S7777  G  07/20/89  07/22/89 

ENTER  THE  RECORD  NUMBER  DESIRED  : 

The  user  is  then  prompted  with,  "WILL  COSTS  BE  ACTUAL  COSTS  OR 

ESTIMATED  COSTS?  (ENTER  AN  A  FOR  ACTTUAL  OR  AN  E  FOR 

ESTIMATED):§."  The  system  takes  the  user’s  response  and  enters  the  correct  cost 

code  into  the  record.  The  system  will  also  total  all  travel  costs  and  update  the  total 

cost  of  travel  field  in  the  record. 

In  the  case  where  the  user  only  wants  to  update  a  record  with  the 
actual  costs  and  selects  this  option  in  the  menu,  the  system  displays  the  same  screen 
in  Figure  52,  except  the  user  can  only  input  the  cost  portions  of  the  screen  format.  The 
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system  then  changes  the  cost  code  and  totals  the  costs  for  the  user  prior  to  updating 
the  record. 


SUBJECT:  AEPLICATION  FOR  CONFERENCE/MISSION  TRAVEL  IN  FISCAL  YEAR  89 


1.  Type  of  Travel  Requested . | 

C-Conference/Meeting  Travel  G-General  Mission  Travel  B-Board  Certification 


2.  ID  CODE  of  person  requesting  the  travel  is  S7396  . 


4.  Purpose  of  Travel  is 
6.  Destination 


8.  Leave  Dates  Starting  Date 
Duration  0  days 


5.  Registration  Fee  $111' 

Mode  of  Travel  is  | 

F-FLY,  G-GOVT  VEH,  P-POV,  O-OTHER 


Ending  Date 


13.  TRAVEL  COST  PER  DIEM  COST  $H|- 

TOTAL  COST  OF  TRAVEL  $  0.00 


imm 

REIMBURSABLES  $| 


EXPENSES  REFLECT  THE  ESTIMATED  COST  OF  TRAVEL 


Figure  52.  Continuing  Medical  Education  Request  Data  Entry  Screen 

Figure  53  depicts  the  input  screen  used  to  add,  change  or  remove 
the  records  in  the  CME  allocation  database.  There  is  only  one  CME  allocation  for  the 
department  for  each  fiscal  year.  Therefore,  the  user  is  always  required  to  enter  the 
fiscal  year  prior  to  using  this  screen  to  enter  the  CME  funds  allocation. 

UPDATE  CME  ALLOCATION 

I  THE  CME  ALLOCATION  FOR  FISCAL  YEAR  89  SHOULD  BE  $  | 


Figure  53.  CME  Allocation  Data  Entry  Screen. 

(6)  Enter,  change,  or  remove  leave/absence  requests.  Figure  54  depicts 
the  data  entry  screen  for  the  absence  database.  Prior  to  using  this  screen,  the  user  must 
first  provide  the  fiscal  year  of  the  request  and  PIC  of  the  person  who  will  be  entered. 
Once  the  PIC  is  entered,  it  is  verified  against  the  personnel  database  and  if  it  is  found. 
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the  standard  confirmation  screen  is  displayed  with  the  message,  "IS  THIS  THE 
PERSON  YOU  EXPECTED?  (Y/N)". 

UPDATE  LEAVE  OR  ABSENCE  REQUEST 

This  is  the  Fiscal  Year  89  Leave  or  Absence  request  for  ID  CODE  S7396 


Type  of  Request  | 


L. 

.Regular  Leave 

E. 

•Emergency  Leave 

T. 

.Other  TDY,  not  CME 

P. 

.Permissive  TDY 

C. 

.Convalescent  Leave 

0. 

. Other 

Starting  Date  Ending  Date 

Duration  0  days 

COtiMENT 

Figure  54.  Leave  and  Absence  Data  Entry  Screen 

If  the  user  is  changing  an  already  existing  record,  the  system  uses 

the  PIC  entered  to  display  the  following: 

RECORD  NO.  ID  CODE  TYPE  START  DATE  END  DATE 

5  S7777  C  06/07/89  07/07/89 

15  S7777  G  07/20/89  07/22/89 

ENTER  THE  RECORD  NUMBER  DESIRED  : 

Since  the  PIC  has  already  been  verified  with  the  confirmation  screen,  only  the  PIC 

number  is  displayed.  The  user  can  then  choose  the  record  desired.  As  discussed 

earlier,  the  ability  to  "point  and  shoot"  to  a  panicular  record  would  enhance  the  user’s 

ability  to  request  a  particular  record.  The  record  is  redisplayed  in  the  same  entry 

fomiat  depicted  in  Figure  54. 

With  each  addition  or  change  of  a  record,  the  system  automatically 
recomputes  the  duration  field  by  subtracting  the  starting  date  from  the  ending  date.  This 
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constant  updating  insures  that  this  field  will  always  be  updated  prior  to  saving  the 
database. 

c.  Outputs 

(1)  Review  Screens.  The  review  of  the  personnel,  TDA,  absence,  and 
CME  request  databases  are  accomplished  by  the  use  of  the  standard  review  screen. 
Each  review  option  provides  the  user  with  the  generic  review  display  described  in 
Section  B  of  this  chapter.  The  data  fields  presented,  with  the  exception  of  the  CME 
request  database  and  the  absence  database,  are  simply  the  fields  existing  in  the 
database.  The  CME  request  database  and  absence  database  are  combined  with  the 
personnel  database  to  create  a  new  temporary  database  that  contains  the  name 
associated  with  each  PIC  in  the  databases.  The  additional  review  fields  displayed  with 
the  already  existing  fields  in  the  CME  request  or  absence  database  are  the  Rank,  First 
Name,  and  Last  name  of  the  person  that  matches  the  PIC  field  in  the  CME  or  absence 
databases. 

(2)  Position  Listing  (see  Figure  55).  This  report  provides  the  Chief 
with  a  listing  of  all  TDA  positions  within  his  department  and  the  personnel  assigned 
to  those  positions.  This  report  is  generated  by  combining  the  TDA  database  with  the 
personnel  database  where  the  TDA  position  in  the  personnel  database  matches  the  TDA 
position  in  the  TDA  database.  If  no  match  is  found,  the  TDA  information  is  printed 
but  with  the  personnel  infonnation  left  blank.  If  the  person  is  carried  as  excess,  their 
information  is  also  printed  but  with  only  the  TDA  paragraph  number,  TDA  line 
number,  and  the  excess  position  code  of  99.  This  report  is  sorted  in  TDA  paragraph 
number,  line  number,  and  position  number  order  whether  the  position  is  filled  or  not. 
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Figure  55.  Position  Listing  Report 

The  fields  necessary  to  create  this  report  are: 
•  Section  Description  for  each  TDA  Paragraph  Number. 


•  TDA  Paragraph  Number. 

•  TDA  Line  Number. 
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TDA  Position  Number. 


•  Authorized  Grade  for  above  TDA  position. 

•  Authorized  MOS  for  the  above  TDA  position. 

•  Authorized  Branch  for  the  above  TDA  position. 

•  TDA  Official  Job  Title. 

•  Rank. 

•  Last  Name. 

•  Authorization  Code  for  the  position. 

•  Doctor  Status  Code.  This  code  reflects  tte  current  residency  status  of  a  doctor 
in  the  residency  program. 

•  Anticipated  date  of  PCS  for  the  person  in  the  position. 

The  following  numbered  items  correspond  with  the  numbers  in 


Figure  55. 

1  This  section  title  correlates  to  the  TDA  paragraph  number  in  the  TDA. 

2  This  subtotal  is  the  total  authorized  positions  within  the  TDA  Paragraph 
number.  This  is  calculated  by  totaling  the  authorized  position  fields  for  each 
paragrt^h  number. 

3  This  is  the  number  of  persons  assigned  to  a  particular  TDA  paragraph.  This 
number  is  calculated  by  counting  the  number  of  TDA  positions  where  the  name 
field  is  not  blank  within  the  same  TDA  paragraph  number. 

4  If  no  name  is  associated  with  a  TDA  position,  the  phrase  "VACANT"  is 
printed  in  this  field. 

5  The  doctor  status  codes  in  the  database.  They  are  also  explained  in  a  foomote 
at  the  bottom  of  the  report. 

6  The  RANK,  FIRST  NAME  and  LAST  NAME  of  the  person  who  occupies  a 
TDA  position  are  concatenated  to  produce  this  field. 
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2  This  total  is  the  total  for  the  department  and  is  a  total  of  all  the  TDA 
paragraphs  subtotals. 

8  Personnel  whose  position  code  is  designated  as  99  do  not  have  a  job  title  since 
they  are  carried  in  an  excess  capacity. 

9  This  flag  indicates  that  the  person  listed  has  an  anticipated  loss  date  that 
is  less  than  60  days  from  the  current  system  date. 

(3)  Section  Update  Worksheet  (see  Figure  56).  This  worksheet  allows 

the  department  to  update  its  personnel  database  with  new  position  information,  changes 

or  additions  to  the  anticipated  loss  date  field,  and  changes  to  the  personnel  status  field. 

This  report  is  very  similar  to  the  position  listing  with  the  exception  of  the  following: 

•  Each  paragraph  within  the  TDA  is  printed  separately  to  facilitate  individual 
delivery  to  sections. 

•  There  are  three  frll  in  the  blank  fields  added  to  allow  the  section  to  directly 
annotate  changes  into  the  worksheet. 

This  report  is  created  from  the  same  combination  of  databases 

necessary  for  the  personnel  listing,  but  only  the  following  fields  are  needed  to  print 

this  worksheet: 

•  Section  Description  for  each  TDA  Paragraph  Number. 

•  TDA  Paragraph  Number. 

•  TDA  Line  Number. 

•  TDA  Position  Number. 

•  TDA  Official  Job  Tide. 

•  Rank. 

•  Last  Name. 
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•  Doctor  Status  Code  for  the  person  who  occupies  the  TDA  position.  (Only 
applies  to  doctors  in  the  residency  program). 

•  Anticipated  date  of  PCS  for  the  person  in  the  position. 


fiCCnOM  WHRIfQMISfrT 

DEPARTMENT  OF  FAMILY  PRACTICE  A  COMMUNITY  MEDICINE 
11  MAR  88 

PARA  UNE  POSN  JOB  TITLE  RANK/NM^E  STATUS  ALOSS 


FAMILY  PRACTICE  CLINIC  (FPC) 


02 

02 


01 

02 

02 

02A 

02A 

oaA 

02A 

00 

00 

M 

02 

O 

02 

02 

02 

02 

02 

02 

02 

02 

02 

04 

00 

OOA 

00 

or 

00 

00 

00 

10 

10 

10 

12 

12 

12 


PARAGRAPH 


01 

01 

02 

01 


01 

02 

02 

04 

00 

00 

07 

02 

00 

10 

11 

12 

1$ 

14 

01 

01 

01 

01 

01 

01 

01 

02 

01 

02 

00 

01 

02 

02 

01 

02 

02 

04 

00 

00 

07 

00 

TOTAL 


I  mya 

I  PHVS 
I  OHVS 
I  PHVS 
I  PHVS 
I  PHys 


PAM  PHTS 
PAMPKyS 
PAM  PHYO 
AUM  PHys 
PAM  PHyo 
PAM  pwys 
PAM  PHY2 
PAM  PHys 
PAM  PHys 
PAM  PHys 
PAM  PHYS 
PAM  PHYS 
PAM  PHYS 
HCAO  NURSE 


MEOSUAQNUR  LT 


AOMIN  8UPV 
CUNIC  NCO 
MCOSP 
MC0  8P 
MEOSP 
MEOSP 
MED  SP 
MED  8P 

MEDCtKCD 
MED  CLK  (T) 
MED  CLK  (T) 
PAM  PHYS 
PAM  P-fY8 
PAM  PHYS 
PAM  PHYS 
PAM  PHYS 
PAM  PHYS 
PAM  PHYS 
MM  PHYS 


AUTHORIZED 


07W7S 


O7RV70 


oonoroo 


ASSIGNED  :  37 


(1)  •  M  VIM  MUOCMCV  O) .  M  YUA  AUlOMCY  ^  .  ifT  VMM  $ 


Figure  56.  Section  Update  Woiksheet 

The  following  numbered  items  correspond  with  Figure  56. 

X  These  fields  are  intentionally  left  Wank  to  allow  the  section  to  input  changes 
to  the  current  TDA  position  listing. 

2  The  RANK  and  LAST  NAME  of  the  person  who  occupies  a  TDA  position 
are  concatenated  to  produce  this  field. 
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(4)  Loss  Report  (see  Figure  57).  This  report  provides  the  department 
with  a  listing  of  all  personnel  who  have  an  anticipated  PCS  date  between  two  user 
specified  dates.  Prior  to  printing  this  repon,  the  user  is  required  to  enter  these  dates 


to  define  the  parameters  for  which  this  report  will  be  printed. 


LOSS  REPORT 

DEPARTMENT  OF  FAMILY  PRACTICE  &  COMMUNITY  MEDICINE 

11  MAR  89 


START  DATE  :  06/01/89 _  ^  ENDING  DATE  :  09/25/89 

The  following  personnel  have  expected  anticipated  loss  dates  within  the 
above  dates: 


RANK NAME 

SECTION 

PCS  DATE 

CPT 

JOHN  SMITH 

AMB 

07/01/89 

OPT 

JANE  DOE 

CTM 

09/01/89 

MSG 

GERY JONES 

CTM 

07/09/89 

1LT 

WAYNE  SHARPE 

FPC 

07/20/89 

Figure  57.  Loss  Report 

This  following  fields  are  necessary  to  print  this  report. 


•  Rank. 

•  Last  Name. 

•  Section  Description  for  the  person. 

•  Anticq}ated  Date  of  Loss. 

The  following  numbered  items  correspond  with  Figure  57. 

1  The  date  parameters  for  the  report  entered  by  the  user. 

2  The  date  in  this  field  must  lie  between  the  parameter  dates  established  by  the 
user. 
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(5)  Vacancy  Listing  (sec  Figure  58).  TTiis  report  provides  a  listing 
of  all  TDA  positions  within  die  department  that  are  vacant.  This  report  provides  the 
Chief  with  a  quick  look  at  his  personnel  shoitages  and  the  current  vacant  positions 
within  the  department. 


VACANCY  REPORT 

DEPARTMENT  OF  FAMILY  PRACTICE  &  COMMUNITY  MEDICINE 
_  11  MAR  89 


The  following  TDA  Positions  are  vaeant: 


PARA  LINE  POSN  GR  MOS  BR  JOB  TITLE  AUTH 


FAMILY  PRACTICE  CLINIC  (FPC) 


532 

03 

13 

03 

61H00 

MC 

FAM  PHYS 

532 

03 

14 

03 

6IHOO 

MC 

FAM  PHYS 

532 

12 

02 

03 

00679 

OS 

MED  CLK  (T) 

PARAGRAPH  SUBTOTAL  ♦**  VACANCIES  :  3—0 


EMERGENCY  MEDICAL  SERVICE  (EMS) 

581  17  01  13  00602  OS  OSN  MED  OFF 

581  17  02  13  00602  OS  OEN  MED  OFF 


YES 

YES 


PARAGRAPH  SUBTOTAL  **♦  VACANCIES  :  2  - - ‘'Q) 


Figure  58.  Vacancy  Listing 

This  report  file  is  generated  in  the  same  manner  as  the  position 

listing  except  that  only  the  TDA  positions  which  do  not  have  a  matching  person 

assigned  to  a  position  are  printed. 

The  following  numbered  items  correspond  with  Figure  58. 

1.  This  is  a  count  of  all  authorized  positions  that  are  vacant  within  a  given  TDA 
paragraph  number.  This  total  represents  the  sum  of  the  authorized  field  for  the 
TDA  paragraph. 
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2  If  the  position  is  authorized  (code=l),  "YES"  is  displayed,  otherwise  "NO"  is 

displayed. 

3  Total  Department  Vacancies.  This  total  is  the  sxun  of  all  TDA  paragr^h 

subtotals  mentioned  in  Note  1  above. 

(6)  Social  Roster  (see  Figure  59).  This  roster  provides  personnel 
within  the  department  a  roster  of  personal  information  of  assigned  personnel  within  the 
department.  This  roster  both  serves  as  a  social  listing  to  facilitate  social  gatherings  and 
as  an  emergency  notification  listing  for  department  personnel.  The  creation  of  this 
report  requires  the  combination  of  the  personnel  database  and  personal  database.  In  the 
case  where  there  is  not  a  match  to  a  personnel  record  in  the  personnel  database,  "NO 
PERSONAL  DATA"  is  printed  in  the  report. 

The  fields  necessary  to  create  this  report  are; 

•  Last  Name. 

•  First  Name  and  Middle  Initial. 

•  Rank. 

•  Branch  of  Service. 

•  Military  Occupational  Specialty  Code. 

•  Arrival  Date  within  the  Department. 

•  TDA  Official  Job  Title. 

•  Section  Description  for  each  TDA  Paragraph  Number. 

•  Local  Home  address. 

•  City  of  Home  address. 

•  State. 

•  Spouse’s  first  name. 


Children’s  names,  followed  by  their  ages  (if  appropriate). 
Home  telephone  number. 

Date  of  rank. 


SOCIAL  ROSTER 

DEPARTMENT  OF  FAMILY  PRACTICE  &  COMMUNITY  MEDICINE 

11  MAR  89 


DEPARTMENT  OF  FAMILY  PRACTICE  (DEPl 


LTC  SMITH,  JOHN  R.  POSN;  C,  DEPT  FP 
BR:  MC  MOS:  61H00  ARR:  07/20/87 

1200  BIRDTREE  LANE 

ANYWHERE  STATE  99999-9999 

PHONE:  (408)999-9999 

WIFE:  BECKY  CHILDREN:  JIM/10,  MIKE/4,  SUE/1 

FAMILY  PRACTICE  CLINIC  (FPC) 

LTC  JONES.  SUE  R.  POSN:  FAM  PHYS 

BR:  MC  MOS:  61H00  ARR:  07/20/88 

1200  SINQASONQ  ROAD 

ANOTHERPLACE  STATE  99999-9999 

PHONE:  (408)888-8888 

WIFE:  N/A  CHILDREN:  BECKY  JOE/1 

MAJ  BURB,  HERB  R.  POSN:  FAM  PHYS 

BR:  MC  MOS:  61H00  ARR:  06/11/85 

23  CHIRPING  TREE  LANE 
ANYWHEREELSE  STATE  99999-9999 

PHONE:  (408)444-4444 
WIFE:  JO  CHILDREN: 


Figure  59.  Social  Roster 
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This  report  is  created  in  the  format  showm  in  Figure  59.  Entries 
are  sotted  by  TDA  paragraph  number  and  then  by  rank  within  the  position  paragraph 
number. 


(7)  Monthly  Absence  Report  (see  Figure  60).  This  report  provides  the 
department  with  a  listing  of  personnel  who  have  planned  absences,  either  a  planned 
(TME  course  or  a  regular  absences  (i.e.,  leave),  within  an  selected  month.  This  report 
is  used  by  the  department  managers  and  the  clinical  director  (see  scheduling 
information  system)  to  manage  personnel  assets  on  a  month  to  month  basis.  The  user 
is  required  to  enter  the  month  and  the  fiscal  year  desired  prior  to  output  of  this  report. 
This  report  is  generated  by  combining  the  absence  database  and  the  CME  request 
database  and  then  combining  this  new  database  with  the  personnel  database  to  get  the 
rank  and  name  of  the  person  who  plans  to  be  absent  in  the  selected  month.  The  report 
file  is  then  sorted  by  section  and  last  name  prior  to  printing. 


MONTHLY  ABSENCE  REPORT 

DEPARTMENT  OF  FAMILY  PRACTICE  &  COMMUNITY  MEDICINE 

1 1  MAR  89 


MONTH  :  JULY 


The  following  personnel  have  planned  absences  during  the  month  of  July: 


RANK  NAME 

OPT  JOHN  SMITH 

OPT  JANE  DOE 

MSQ  OERY  JONES 


1LT  WAYNE  SHARPE 
SOT  WAYNE  ROGERS 


— 

d  abs^^t 


■♦FISCAL  YEAR  :  89 


SECTION 

AMB 

CTM 

CTM 

PPG 

POM 


START  DATE  END  DATE  TYPE 

07/01/69  07/1  S^SO  CME 


00/01/89 

07/09/89 

07/20/89 

07/30/89 


07/02/89 

08/2^89 

07/22/89 

08/30/89 


,,-^^EMER  LV 
LEAVE 

ORDTDY 


Figure  60.  Monthly  Absence  Report. 
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The  fields  required  to  produce  this  report  are; 

•  Rank  of  the  person  who  has  an  absence  planned  during  the  requested  month. 

•  Last  Name. 

•  First  Name. 

•  Section  of  assignment. 

•  Start  date  of  planned  absence. 

•  End  Date  of  planned  absence. 

•  Type  of  Absence. 

The  following  numbered  items  correspond  with  Figure  60. 

1  The  fiscal  year  and  month  desired  are  entered  by  the  user  prior  to  output  of 
report.  If  the  record  in  the  combined  database  falls  within  the  requested  start  date 
or  end  date,  the  absence  record  is  included  within  the  report.  If  the  record  is 
inclusive  of  the  requested  start  and  end  date,  e.g.,  a  request  in  July  falls  between 
a  user  specified  start  date  in  June  and  an  end  date  August,  the  record  will  be 
included  in  the  report. 

2  Section  codes  are  sorted  to  keep  personnel  along  organizational  lines.  The 
secondary  sort  is  on  the  last  name. 

3  Type  request  code  is  converted  to  its  full  text  format.  Care  must  be  taken  not 
to  assign  the  same  type  code  to  both  the  CME  database  and  the  absence  database. 

4  The  RANK,  FIRST  NAME,  and  LAST  NAME  fields  are  concatenated  to  give 
the  appearance  that  the  field  is  one  field. 

(8)  Fiscal  Year  Summary  of  Physician  Absences  (see  Figure  61).  This 

summary  report  provides  the  Department  Chief  with  the  ability  to  monitor  and  evaluate 

the  number  of  and  frequency  of  doctor  absences  within  the  department.  This  report 

serves  as  an  indicator  of  doctor  availability  over  the  fiscal  year  and  shows  the 

frequency  of  absences  by  type  of  request.  This  report  is  generated  in  the  same  manner 

as  described  in  the  absence  report  except  this  report  is  not  restricted  to  one  month  and 


extracts  only  doctor  information.  The  user  is  only  required  to  enter  the  fiscal  year 
desired.  The  fields  necessary  to  generate  this  report  are  the  same  as  the  absence  report 
but  also  include  the  duration  field  from  both  of  the  databases. 


FISCAL  YEAR  ABSENCE  SUMMARY 
DEPARTMENT  OF  FAMILY  PRACTICE  & 
COMMUNITY  MEDICINE 
1 1  MAR  89 


FISCAL  YEAR  :  89 


NAME  START  DATE  END  DATE 


LTC  JOHN  SMUCK 

TYPE  :  CME  REQUEST 
01/01/89 
06/05/89 

Subtotal . 

TYPE  :  ORDINARY  LEAVE 
03/05IQ9 
06/10/89 

Subtotal . 


Total. 


LTC  JANE  SMITH 


.TYPE  :  CME  REQUEST 
03/01/89 
04/01/89 
05/05/89 

Subtotal . 

►TYPE  :  PERMISSIVE  TDY 
09/25/89 

Subtotal . 

•TYPE  :  ORDINARY  LEAVE 
02/01/89 

Subtotal . 


01/30/89 

06/10/89 


03/30/89 

06/20/89 


03/30/89 

04/19/89 

05/15/89 


09/30/89 


02/28/89 


DURATION 


days 


29 

18 

IP 

57 


5 

5 


27 

27  is 


Total 


SI  days 


Figure  61.  Fiscal  Year  Summary  of  Physician  Absences. 
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The  following  numbered  items  correspond  with  Figure  61. 

1  Each  person  identified  as  having  at  least  one  absence  during  the  fiscal  year  is 
reported  in  last  name  order. 

2  Under  each  person,  all  absences  are  sorted  by  request  type  in  alphabetical  order 
with  breaks  between  different  types  of  absences. 

3  Duration  is  extracted  directly  from  the  databases  reflecting  the  End  Date  minus 
the  Start  Date  in  days. 

4  Subtotal  of  the  duration  for  each  type  of  absence,  for  each  person. 

5  Total  duration  for  all  absences  for  the  given  person. 

(9)  CME  Reports  (Actual  and  Estimated)  (see  Figures  62  and  63). 
These  reports  allow  the  Department  Chief  to  monitor  the  CME  expenditures  and 
estimate  the  funds  remaining  for  a  given  fiscal  year.  The  CME  reports  are  critical  in 
keeping  track  of  the  limited  funds  available  to  send  doctors  to  the  training  necessary 
to  keep  them  certified  in  critical  medical  skills. 

These  two  reports  are  very  similar  but  are  used  in  separate  contexts. 
The  Actual  CME  Budget  Expenditure  Report  is  used  to  report  the  amount  actually 
spent  during  a  given  fiscal  year,  excluding  all  estimated  costs  figures.  This  report  gives 
the  Department  Chief  an  accurate  look  at  the  funds  remaining  for  the  requested  fiscal 
year.  The  Estimated  CME  Budget  Expenditure  report  not  only  gives  the  Chief  a  look 
at  what  funds  have  actually  been  spent,  but  also  provides  a  listing  of  the  approved 
CME  funded  travel  for  which  travel  claims  have  not  yet  been  settled.  This  report  is 
also  used  at  the  beginning  of  the  fiscal  year  to  report  the  projected  expenditures  for 
a  requested  fiscal  year. 
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CONTINUING  MEDICAL  EDUCATION 
ACTUAL  FUNDS  REPORT 


DEPXRtMEWT  Of  FAMILY  PRACTICE 
CO>»(UNITY  Ht6lCINE  (TDX< 


11  DEC  89 


RAKK  DKTES  OF  TDY 


LOCATION 
OF  TDY 


REASON 
FOR  TDY 


TRAVEL 

COST 


PER 

DIEM 


SMITH,  JOHN 
JONES,  JANE 


CRT  09/09/89-09/20/89 
MAJ  10/10/89-11/20/89 


LAS  VEGAS,  NV 
RENO,  NV 


ORTHO 

AOA 


147.00  320.00  395.00 
189.2$  437.50  210.00 


FDNDS  ALLOCATED  t 


CME  TRAVEL  APPROVED  HOT  NOT  COMPLETED  (ESTIMATED  COSTS) 

PROJECTED  FUNDS  RGMAJNING 

Figure  62.  Actual  CME  Budget  Expenditure  Report 


CONTINUING  MEDICAL  EDUCATION 
ESTIMATED  FUNDS  REPORT 


DEPARTMENT  OF  FAMILY  PRACTICE 

>jl&!g7Wk~ffbA) 


11  DEC  89 


RANK  DATES  OF  TDY 


LOCATION 

or  TDY 


REASON  TRAVEL  PER 
FOR  TOY  COST  DIEM 


REG  REIKB 
FEE  COST 


TOTAL' 

COST 


OHCOMflTTED 

FUNDS 


FUNDS  ALLOCATED  t 


SMITH, 

JOHN 

CPT 

01/05/89-01/20/89 

LAS 

VEGAS, 

NV 

ORTHO 

147.00 

320.00 

395.00 

0 

862.00 

JONES, 

JANE 

MAJ 

05/10/89-05/20/89 

RENO,  NV 

AOA 

169.25 

437.50 

210.00 

SO 

866.75 

ANDERS. 

.  KEN 

CPT 

07/20/89-08/15/89 

SAN 

DltOO, 

CA 

EMERG 

100.00 

400.00 

200.00 

50 

750,00 

ALL  eSTZMATCO  AND  ACTUAL  TRAVEL  COSTS  REPORTED  HERE 


n 


PROJECTED  FUNDS  REMAINING  14311.17 

Figure  63.  Estimated  CME  Budget  Expenditures  Report 

The  user  is  required  to  enter  the  fiscal  year  of  the  report  prior  to 
creation  of  either  report.  The  fields  required  to  create  these  reports  are. 

•  Last  Name  of  requestor. 

•  First  Name. 

•  Rank  of  the  requestor. 

•  Start  and  End  dates  of  travel. 

•  Destination. 
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•  Puipose  of  Request,  e.g.,  ORTHO  WORKSHOP. 

•  All  Costs  of  travel,  including  the  Travel  Cost,  Per  diem  costs,  registration  fee, 
reimbursable  expenses,  and  total  cost  fields  of  the  request. 

•  Cost  Code,  whether  it  is  an  actual  accrued  cost  or  an  estimated  cost  of  the 
travel. 

•  Allocated  CME  budget  for  the  Hscal  year  from  the  CME  allocation  database. 

To  create  this  report  requires  that  the  CME  request  database  be 
combined  with  the  persoimel  database  to  match  the  name  of  a  person  with  die  PIC  in 
the  CME  request  database.  The  CME  allocation  database  is  also  used  to  determine  the 
actual  allocation  for  the  selected  fiscal  year. 

The  following  numbered  items  correspond  with  the  numbers  in 

Figures  62  and  63. 

1  This  number  is  the  actual  allocation  for  the  current  fiscal  year  selected. 

2  This  is  an  accumulated  total  of  the  actual  costs  incurred  for  the  current  fiscal 

year. 

3  This  number  reflects  the  allocation  for  the  current  fiscal  year  minus  the  actual 

expenses  already  incurred. 

4  This  figure  is  the  previous  allocation  minus  the  total  cost  of  travel  for  the 

current  record. 

4.  Scheduling  Information  System 

We  concluded  in  Chapter  IV  that  although  automating  the  scheduling  system 
would  be  impractical,  improvements  could  be  made  in  the  system  by  standardizing  the 
forms  used  in  data  collection  and  reporting. 

Figure  64  is  the  UCD  depicting  the  proposed  scheduling  system.  Although 
most  of  the  scheduling  process  will  remain  the  same,  the  clinical  director  will  now  be 
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able  to  get  pre-printed  standard  forms  for  recording  doctor  availability  information. 
These  forms  can  be  created  with  commercially  available  software  packages  (e.g., 
FORMTCX)L)  and  maintained  on  diskettes  in  the  administration  office. 


Doctor  Monthly 
Schedule 


Create 

Doctor 

Schedules 


/  Department 
/  Appointment 
\  System 
\  (COSTARS) 


Record 

Doctor 

Informot'on 


Doctor 
Availability 
Information 


Clinicol  Director 

Scheduling 
Folder 


Doctor  Information 


Blonk  Forms 


Figure  64.  Scheduling  User  Concept  Diagram 
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After  discussions  with  the  clinical  director,  it  was  determined  that  the  most 


valuable  forms  to  standardize  are  the  duty  history  sheet,  the  mondily  cumulative  tally 
sheet,  and  the  clinic  schedule  template.  Other  sotuces  of  information  such  as  the  3x5 
cards  containing  staff  doaor  and  resident’s  special  availability  instnictions  were 
considered  to  be  adequate  in  their  current  form.  The  resulting  forms  are  shown  in 
Figures  65  and  66. 

Figure  65  is  the  Duty  History  Record  which  is  a  combination  of  the  duty 
history  sheet  and  the  monthly  cumulative  tally  sheet.  A  completed  duty  history  record 
will  provide  the  scheduler  with  a  comprehensive  history  of  each  doctor’s  on  call  duty. 

Figure  66  is  the  clinic  schedule  template.  Since  this  form  is  a  template, 
the  staff  doctors  permanent  schedules  are  included.  The  template  can  be  penciled  in 
by  the  scheduler  to  show  residents’  schedules  for  the  month.  The  resident’s  names  can 
then  be  entered  into  the  form  using  the  fill-in-form  option  of  FORMTOOL  and  a 
complete  schedule  can  be  printed  for  distribution.  The  clinical  director  liked  the  idea 
of  the  template.  The  tenqrlate  can  be  changed  easily  and  each  month  a  clean  template 
can  be  used  without  having  to  first  delete  the  resident’s  names  firom  the  previous 
month’s  schedule. 

•^^6 _  Duly  History  Record 


Figure  65.  Duty  History  Record 
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Month  Y r  _ Schedule  Template 


TEAMS 

MONDAY 

TUESDAY 

WEDNESDAY 

THURSDAY 

FRIDAY 

Gold  A 

M 

Lorenzen 

Mork 

Foster 

Birdsong 

Landauer 

Crisp 

Splnelll 

Herman  P 

Terrlo,  H  M 

Foster 

Lorenzen 

Foster 

Mork 

Foster 

Lorenzen 

Mork 

Foster 

Mork 

Mork 

Foster 

Red  A 

M 

Forred 

Hutnak 

Lee 

Schmidt 

Walcott 

Bradley 

Sorensen 

P 

M 

Forred 

Forred 

Fuller 

Fuller 

Forred 

Fuller 

Forred 

Forred 

Fuller 

Fuller 

Blue  A 

m| 

Kugler 

Spaulding 

Yeash 

Ard 

Runkle 

Davis  ^ 

Goodrich 

Swann 

Terrio,J  P 

Weaver  M 

1 

Spaulding 

Kuglet 

Spaulding 

Yeash 

Kugler 

Yeash 

Spaulding 

Fitzharris 

Yeash 

Spaulding 

Kugler 

Yeash 

Fltzharrls 

Kugler 

1 

Spaulding  | 

i 

Kugler 

Yeash 

Figure  66.  Schedule  Template 
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5.  Patient  Satisfaction  Information  System  (see  Program,  Appendix  F) 
a.  Data  Structures 

As  can  be  seen  in  the  UCD  in  Figure  67,  the  entire  patient  satisfaction 
system  hinges  on  completed  patient  surveys,  the  results  of  which  are  entered  into  a 
survey  database  for  use  in  report  generation. 


Comphtmd  Survey 


QA  R«p,  Clark 


Rmporit 


Cllnie  ^ 

O.P..  \ 

Reports 

1 

Reports 

Input  Dote 


7 


CItnIee 


* 

ChUt 


QA  Rep,  Clerk 


Figure  67.  Patient  Satisfaction  User  Concept  Diagram 

The  approved  opinion  survey,  designed  in  cooperation  with  the 
Department  Chief  and  the  Quality  Assurance  (QA)  representative,  is  shown  in  Figure 
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68.  The  questions  and  answers  cover  those  areas  of  most  concern  to  the  Department 
Chief.  The  survey  form  determines  the  data  structure  of  the  database  itself,  with  data 
fields  corresponding  to  each  question.  The  ft^owing  data  fields  are  used  in  the 
database  to  record  survey  data. 

•  Month.  The  month  the  survey  was  completed  by  the  patient. 

•  Year.  Calendar  year  the  survey  was  taken. 

•  Section  Code.  Same  as  systems  above. 

•  Doctor’s  Name.  The  name  of  the  doctor  seen  by  the  patient  completing  the 
survey. 

•  Appointment  Days.  Question  lA. 

•  Appointment  Acceptability.  Question  IB. 

•  Records  Ready.  Question  2. 

•  Waiting  Time.  Question  3A. 

•  Waiting  Acceptability.  Question  3B. 

•  Receptionist  Courtesy.  Question  4. 

•  Nursing  Courtesy.  Question  5. 

•  Doctor  Courtesy.  Question  6 

•  Procedures  Explanations.  Question  7. 

•  Time  Spent  With  Doctor.  Question  8. 

•  Qinic  Oeanliness.  Question  9. 

•  Overall  Satisfaction.  Question  10. 

•  Patient  Comments  to  Enter?.  The  user  entering  the  survey  results  into  the 
survey  database  must  enter  a  "Y"  in  this  field  to  indicate  there  are  comments 
to  be  added  to  the  database  for  this  survey.  An  "N"  indicates  there  are  no 
comments.  The  following  section  on  Inputs  explains  this  further. 


164 


Comments.  A  memo  field  which  the  user  can  fill  from  comments  made  on  the 
patient  surveys. 


Department  of  Family  Practice 
Patient  Opinion  Survey 

Your  opinion  is  Important  to  us.  Please  complete  this  survey  and  return  it 
to  the  box  located  at  the  reception  desk. 

Sincerely, 

_  _  Chief,  Department  of  Family  Practice 


PLEASE  CIRCLE  THE  ANSWER  TO  THE  RIGHT  OF  EACH  QDESTTON 


l.A.How  many  days  did  it  1)  Same  2)  Less  3)  Less  4)  Less  5)  More 

take  to  get  your  Day  than  7  than  14  than  30  than  30 

appointment? 


6. Has  this  time 
acceptable? 


1)  Acceptable 


2)  Not  Acceptable 


2. Here  your  records  ready 

at  the  front  desk?  1)  YES 


3. A. How  long  did  you  wait  1)  Less  2)  Less  3)  Less  4)  Less  5)  More 

to  see  the  doctor?  than  than  than  than  than 

15  min  30  min  45  min  1  hour  1  hour 


B.Was  the  waiting  time 
acceptable? 


1)  Acceptable 


2)  Not  Acceptable 


PLEASE  CIRCLE  THE  NUMBER  TO  THE  RIGHT  OF  EACH  QUESTION  WHICH  MOST  CLOSELY 
MATCHES  YOUR  OPINION  BASED  ON  TllE  FOLLOWING  SCALE: 

5=Excellent  4—Good  3-OK  2“Need3  Improvement  l«Unsat isf actory 


4.  Courtesy  of  receptionists. 

5.  Courtesy  of  nursing  staff. 


6.  Courtesy  of  doctor. 


7.  Explanation  of  procedures  (lab  work,  EKG' s,  etc) 


8.  The  amount  of  time  the  doctor  spent  with  you. 


9.  The  general  cleanliness  of  the  clinic. 


10.  Overall  satisfaction  with  the  care  you  received. 


THANK  YOU  ! 


Figure  68.  Opinion  Survey  Form 


b.  Data  Inputs 

The  Patient  Opinion  menu  hierarchy  chart  is  depicted  in  Figure  69. 
The  user  can  enter  new  survey  data  using  the  input  screen  shown  in  Figure  70.  This 
input  screen  contains  all  of  the  data  base  fields  arranged  in  a  format  similar  to  the 
actual  survey  for  simplified  data  entry.  The  answers  to  the  survey’s  numbered 
questions  are  coded:  the  user  simply  enters  one  number  corresponding  to  the  survey 
answer.  Since  each  question  has  a  predetermined  number  of  responses,  error  checking 
is  simply  a  matter  of  verifying  the  input  number  falls  in  the  allowable  range.  For 
example,  question  lA  has  five  possible  answers.  If  the  user  entered  anything  other 
than  one  through  five,  a  bell  would  sound  and  a  message  saying  the  input  was  out  of 
range  would  appear  at  the  bottom  of  the  screen.  The  user  is  then  given  the  chance  to 
enter  the  correct  answer.  At  the  bottom  of  the  input  screen  the  user  is  asked  if  there 
are  comments  to  be  entered.  The  user  enters  a  "Y"  or  "N"  in  the  Patient  Comments 
to  Enter  field.  The  Patient  Comments  to  Enter  field  is  necessary  when  printing  the 
patient  comments  report  discussed  in  Outputs  below  because  a  memo  field  in  the 
database  program  carmot  be  used  to  determine  records  to  print.  Therefore,  it  is 
necessaiy  to  have  a  second  field  whose  value  indicates  whether  the  comment  field  is 
filled  to  allow  only  those  records  with  comments  to  be  printed. 

The  use  of  mark-sense  forms  would  allow  automatic  entry  of  the  survey 
data  into  the  database.  Unfortunately,  neither  the  department  nor  the  hospital  has  the 
computer  hardware  to  read  mark-sense  forms  and  there  are  no  plans  to  acquire  such 
technology.  Additionally,  we  feel  the  added  complexity  of  mark-sense  forms,  e.g., 
special  marking  requirements  and  additional  instructions,  would  deter  some  patients 
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from  completing  the  surveys.  Also,  the  requirement  to  purcha.se  specially  designed 
forms  may  deter  the  department  from  obtaining  the  surveys. 


PATIENT  OPINION  SYSTEM 


Figure  69.  Patient  Satisfaction  Menu  Hierarchy  Chart 


iriiTH 


YEA<» 


SECTION  CODE 


DOCTCP, 


l.A.  Days  to  get  appointment. 

l.A, 

1| 

B.  Accoptaibility . 

B. 

J 

2.  Records  ready  on  time. 

2 

1 

3, A.  Waiting  time. 

3. A.  1 

1 

B.  Acceptability. 

B.  1 

m 

4.  Courtesy,  receptionists. 

4. 

1 

5.  Courtesy,  nurses. 

5. 

■ 

6.  Courtesy,  doctors. 

6. 

■ 

7.  Explanation  of  procedures. 

1. 

■ 

8.  Time  spent  with  doctor. 

8. 

■ 

9.  Cleanliness. 

9. 

■ 

10.  General  satisfaction. 

10. 

1 

ARE  THERE  COMMENTS  TO  ADD?  (Y/N)  | 
(Cntrl  PgDn  to  Enter  Coinwents) _ "memo 


Figure  70.  Patient  Satisfaction  Input  Screen 


Once  the  survey  data  is  entered  into  the  database,  the  user  can  print 
one  of  several  reports.  After  selecting  the  report  desired  from  the  menu,  the  user  is 
prompted  to  enter  information  which  further  identifres  the  report  parameters  such  as 
year,  month,  and  (if  necessary)  the  clinic’s  section  code.  This  information  is  used  to 
gather  the  data  necessary  to  create  the  desired  output, 
c.  Outputs 

(1)  Access  to  Care  Reports  (see  Figure  71).  There  are  two  access  to 
care  reports,  one  for  the  department  as  a  whole,  and  one  for  each  clinic.  Both  consist 
of  two  parts  and  are  identical  in  content  and  apprearance.  However,  for  clinic  reports, 
only  the  sirrvey  data  for  the  selected  clinic  is  used.  Pjtt  One  of  the  rqport. 
Acceptability  of  Appointment  Access  indicates  to  the  Department  Chief  the  patients’ 
opinions  on  the  acceptability  of  the  length  of  time  it  took  them  to  obtain  an 
appointment.  Part  Two,  Average  Days  to  Get  Appointment,  allows  the  Department 
Chief  to  examine  the  trend  in  the  average  number  of  days  to  get  an  appointment. 

The  following  fields  are  necessary  for  creating  the  two  part  access 

to  care  reports. 

•  Month. 

•  Year. 

•  Section  Code.  For  clinic  report  only. 

•  Appointment  Days. 

•  Appointment  Acceptability.  Required  only  for  Part  1,  Acceptability  of 
Appointment  Access. 
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Figure  71.  Access  to  Care  Report 


The  following  numbered  items  coirespond  to  the  numbers  shown 
in  Figure  71  and  explain  the  data  man^ulations  and  calculations  required  to  produce 
the  repoit. 

1.  The  total  number  of  responses  for  each  possible  answer  to  survey  question  lA 
are  graphed  along  the  Y-axis  based  on  note  2  below. 

2  For  each  possible  answer  to  question  lA,  the  number  of  patients  who 
responded  to  question  IB  as  acceptable  and  unacceptable  are  counted  and  each 
coimt  is  graphed  as  a  separate  bar.  For  example,  in  the  Hgure,  for  those  patients 
that  said  it  took  them  less  than  seven  days  to  get  an  appointment,  IS  said  this 
was  acceptable  and  one  said  this  was  unacceptable. 

3  The  total  response  line  shows  the  total  responses  for  each  possible  answer  to 
question  lA,  appointment  days. 

4  This  is  the  month  and  year  of  the  survey.  This  data  is  input  by  the  user  when 
requesting  the  report  and  is  used  by  the  program  to  select  the  appropriate  survey 
database  records. 

5  In  Part  Two,  the  days  to  get  an  appointment  are  graphed  on  the  Y-axis. 

6  The  responses  to  question  lA  are  averaged  for  each  month  of  the  desired  year 
and  plotted  along  the  X-axis. 

(2)  Waiting  Time  Reports  (see  Figure  72).  As  with  the  access  to  care 
reports,  there  are  two  waiting  time  reports,  one  for  the  department  as  a  whole,  and  one 
for  each  clinic.  The  foimat  of  the  waiting  time  report  is  similar  to  the  access  to  care 
report  for  both  department  and  clinic.  Part  One  of  the  report,  Acceptability  of  Waiting 
Time  indicates  to  the  Department  Chief  the  patients’  opinions  of  the  acceptability  of 
the  length  of  time  it  took  them  to  be  seen  by  the  doctor.  Part  Two,  Average  Waiting 
Time,  denotes  the  trend  over  the  calendar  year  of  the  average  waiting  time  to  see  a 
doctor. 
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Acceptability  of  Waiting  Time 


The  following  fields  are  necessary  for  creating  the  two  part  waiting 

time  reports. 

•  Month. 

•  Year. 

•  Section  Code.  For  clinic  report  only. 

•  Waiting  Time. 

•  Waiting  Acceptability.  Required  only  for  Part  One,  Acceptability  of  Waiting 
Time. 

The  following  numbered  items  correspond  to  the  numbers  shown 
in  Figure  72  and  explain  the  data  manipulations  and  calculations  required  to  produce 
the  report. 

1.  The  total  number  of  responses  for  each  possible  answer  to  survey  question  3A 
are  graphed  along  the  Y-axis  based  on  note  2  below. 

2  For  each  possible  answer  to  question  3A,  the  number  of  patients  who 
responded  to  question  3B  as  acceptable  and  unacceptable  are  counted  and  each 
coimt  is  graphed  as  a  separate  bar.  For  example,  in  the  figure,  for  those  patients 
that  said  it  took  them  less  than  30  minutes  to  see  a  doctor,  17  said  this  was 
acceptable  and  three  said  this  was  unacceptable. 

3  The  total  response  line  shows  the  total  responses  for  each  possible  answer  to 
question  3A,  waiting  time. 

4  This  is  the  month  and  year  of  the  survey.  This  data  is  input  by  the  user  when 
requesting  the  report  and  is  used  by  the  program  to  select  the  appropriate  survey 
database  records. 

5  In  Part  Two,  the  waiting  time  is  graphed  on  the  Y-axis. 

6  The  responses  to  question  3  A  are  averaged  for  each  month  of  the  desired  year 
and  plotted  along  the  X-axis. 

(3)  Satisfaction  Indicators  (see  Figure  73).  Questions  four  through  ten 
of  the  survey  are  statements  for  which  the  patient  is  asked  to  indicate  his  level  or 
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degree  of  satisfaction  ranging  from  five  for  excellent  to  one  for  unsatisfactory.  The 
Satisfaction  Indicator  report  shows  the  results  of  the  survey  in  these  seven  areas,  with 
the  total  number  of  responses  for  each  level  of  satisfaction  (one  through  five)  graphed 
for  each  of  the  seven  areas. 


Number  of  Responses 


Satisfaction  Indicators 

July!  989 

@ 


Recept  Nunes 


Excellent 


Doctor  Explain  Time  Spent  Clean 
Satisfaction  Indicators  (3) 

Satisfaction  Levels 

OK  HI  Need  Improvement 


OveraU 


Good 


Unsat 


Figure  73.  Satisfaaion  Indicators 

The  following  fields  are  necessary  for  creating  this  report: 

•  Month. 


Year. 

Section  Code.  For  clinic  report  only. 
Receptionist  Courtesy. 


•  Nursing  Courtesy. 

•  Doctor  Courtesy. 

•  Procedure  Explanations. 

•  Time  Spent  With  Doctor. 

•  Qinic  Cleanliness. 

•  Overall  Satisfaction. 

The  following  numbered  items  correspond  to  the  numbers  in  Figure 
73  and  explain  the  data  manipulations  required  to  produce  the  gr^h. 

1  The  Month  and  Year  for  the  report. 

2  The  total  number  of  responses  in  each  level  of  satisfaction  are  graphed  along 
the  Y-axis. 

3  For  each  satisfaction  indicator  (e.g.,  doctor  courtesy,  overall  satisfaction)  the 
number  of  responses  in  each  level  of  satisfaction  (note  4  in  the  figure)  are 
counted  and  the  total  for  each  level  is  graphed  as  a  separate  bar  for  all  of  the 
indicators  along  the  X-axis. 

(4)  Average  Satisfaction  Levels  (see  Figure  74).  This  two  part  report 
shows  the  average  level  of  satisfaction  for  each  satisfaction  indicator  for  the  calendar 
year.  It  is  presented  in  two  reports  to  simplify  viewing.  The  Department  Chief  prefers 
line  graphs  to  enhance  trend  identification  so  the  seven  indicators  are  divided  into  two 
groups.  Part  One  shows  the  indicators  which  are  primarily  personnel  oriented  (e.g., 
courtesy)  plus  overall  satisfaction.  Part  Two  shows  the  remaining  indicator’s  averages. 

The  following  fields  are  necessary  to  create  the  two  part  report: 

•  Month. 

•  Year. 

•  Section  Code.  For  clinic  report  only. 
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•  Receptionist  Courtesy.  For  Part  One  only. 

•  Nursing  Courtesy.  For  Part  One  only. 

•  Doctor  Courtesy.  For  Part  One  only. 

•  Overall  Satisfaction.  For  Part  One  only. 

•  Procedure  Explanations.  For  Part  Two  only. 

•  Time  Spent  With  Doctor.  For  Part  Two  only. 

•  Qinic  Qeanliness.  For  Part  Two  only. 

The  foUowing  numbered  items  correspond  to  the  numbers  in  Figure 
74  and  explain  the  data  manipulations  required  to  produce  this  report. 

1  This  is  the  requested  year  of  the  survey  data  for  the  report. 

2  The  average  of  all  of  the  values  (ranging  from  one  to  five)  for  each  indicator 
is  calculated  for  each  month  of  the  specified  year.  The  satisfaction  indicators  are 
plotted  along  the  X-axis  using  different  line  styles  for  each  indicators  average 
values. 

3  The  average  response  for  each  indicator  is  correlated  to  it’s  equivalent  narrative 
description,  i.e.,  1  =  unsatisfactory,  and  these  are  shown  along  the  Y-axis. 

(5)  Doctor  Satisfaction  Report  (see  Figure  75).  This  report  is  a  table 
showing  the  average  responses  for  a  given  month  for  four  of  the  satisfaction  indicators 
which  most  directly  relate  to  the  patient’s  interactions  with  the  doctors.  This  report 
is  produced  for  all  of  the  doctors  in  the  department  and  allows  the  Department  Chief 
to  track  individual  doctor’s  survey  results. 
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Average  Satisfaction  Levels 


Indicators 

^  Explanations  '  Time  Spent  (DRs)  — Cleajiliness 

Figure  74.  Average  Satisfaction  Levels  Report 
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DOCTOR  SATISFACTION  REPORT 


® 

DOCTOR 

COURTESY 

July  1989 
© 

EXPLANATIONS  TIME  SPENT 

GENERAL 

© 

OVERALL 

Baker 

3.5 

3.0 

4.0 

SATISFACTION 

4.0 

AVG 

3.6 

Foster 

4.0 

4.2 

3.6 

4.0 

4.0 

Kugler 

3.0 

2.8 

3.4 

3.2 

[S  J  3.1 

Lorenzen 

4,5 

4.0 

4.7 

4.5 

^  4.4 

Mork 

4.0 

4.0 

3.7 

4.0 

3.9 

Yeash 

3.0 

4.3 

2.8 

4.0 

3.5 

Figure  75.  Doctor  Satisfaction  Report 

The  following  fields  are  necessary  for  creating  this  report: 

•  Year. 

•  Month. 

•  Doctor  Name. 

•  Doctor  Courtesy. 

•  Procedure  Explanations. 

•  Time  Spent  With  Doctor. 

•  Overall  Satisfaction. 

The  numbered  items  below  correspond  to  Figure  75  and  explain 
how  the  data  for  the  report  is  obtained. 

_!  TTiis  is  the  month  and  year  for  the  report. 

2  Each  doctor’s  name  is  printed  in  the  first  column  in  alphabetical  trder. 

3  For  each  doctor,  the  average  resp)onse  for  the  four  indicators  is  calculated  and 
placed  in  the  corresponding  column  adjacent  to  the  doctors  name. 

4  The  value  of  all  four  indicators  is  averaged  to  produce  an  overall  doctor 
satisfaction  average. 

5  An  additional  indicator  of  a  physician’s  consistency  could  be  computer  here, 
e.g.,  standard  deviation  or  some  similar  measure  of  dispersion. 
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(6)  Patient  Comments  (see  Figure  76).  This  report  is  a  print  out  of 
all  of  the  patient  comments  entered  into  the  survey  database  for  the  desired  month  and 
year.  It  allows  the  Department  Chief  to  review  any  constructive  criticisms  or 
noteworthy  suggestions  made  by  the  patients  and  pinpoint  other  trouble  areas  (or 
outstanding  areas)  which  cannot  be  identified  from  the  quantitative  portion  of  the 
survey. 

The  fields  necessary  to  produce  this  report  are  listed  below: 

•  Month. 

•  Year. 

*  Patient  Comments  to  Enter? 

*  Comments. 


The  numbered  items  below,  corresponding  to  Figure  76,  explain 


the  comment  report. 


1  The  month  and  year  of  the  report  is  listed  at  the  top. 

2  The  records  in  the  database  which  have  the  Comments  field  filled  (indicated 
by  a  "Y"  in  the  Patient  Comments  to  Enter  field)  are  printed  in  record  number 
order  for  the  month  and  year. 

PATIENT  COMMENTS 
^  July  1989 

I  THINK  THE  LAB  AND  PHARMACY  TAKE  TOO  LONG,  I  WAITED  FOR  MORE  THAN  AN  HOUR 
TO  GET  MY  PRESCRIPTION  FILLED. 

THE  FAMILY  PRACTICE  CLINIC  IS  GREAT  HERE.  I  WOULD  LIKE  TO  BE  ABLE  TO  SEE 
MY  ASSIGNED  DOCTOR  MORE  OFTEN,  DR.  YEASH,  BUT  WHOEVER  SEES  ME  IS  ALWAYS 
VERY  COURTEOUS  AND  HELPFUL. 

I  NEVER  GET  TO  SEE  THE  DOCTOR  WHICH  MY  FAMILY  IS  ASSIGNED  TO,  WHY  BOTHER 
GOING  THROUGH  THE  HASSLE  OF  SIGNING  UP  FOR  A  SPECIFIC  DOCTOR? 

ITS  TOO  COLD  IN  THE  EXAMINING  ROOMS. 


Figure  76.  Patient  Comments  Report 
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6.  Productivity  Information  System  (see  Program,  Appendix  G) 
a.  Data  Structures 

The  productivity  system  UCD  is  shown  in  Figure  77.  The  functions 
of  the  productivity  system  depend  on  visit  information  obtained  from  the  Patient 
Administration  Division  for  each  section  of  the  department.  The  method  of  obtaining 
the  visit  information  is  described  in  the  next  section,  Ii^uts. 


The  visit  information  is  entered  into  the  visit  database  which  consists 
of  the  following  fields: 

•  Fiscal  Year.  The  fiscal  year  is  used  so  the  number  of  visits  in  each  section  can 
be  directly  compared  to  the  section’s  expenditures  for  each  month. 
Expenditure  data  is  maintained  in  the  budget  database  by  fiscal  year. 

•  Month. 

•  Section  Code. 

•  Number  of  Visits.  The  number  of  patient  visits  for  each  section  within  the 
department  as  reported  by  the  Patient  Administration  Division. 

b.  Data  Inputs 

The  productivity  system  menu  hierarchy  chart  is  shown  in  Figure  78. 
Visit  data  for  the  entire  hospital  is  collected  monthly  by  the  Patient  Administration 
Division  (PAD)  for  RMD.  PAD  enters  each  section’s  visit  information  into  a 
spreadsheet  program  which  they  use  to  create  the  MED  302  report,  discussed  in 
Chapters  HI  and  IV.  For  the  department  productivity  system,  the  visit  information  can 
be  extracted  from  the  PAD  MED  302  file  for  entry  into  the  visit  database.  Table  VI 
shows  the  locations  of  visit  data  in  the  MED  302  spreadsheet  file  corresp>onding  to 
each  section  in  the  DFPCM.  As  can  be  seen  in  the  Table  VI,  some  calculations  on 
the  data  in  the  file  are  necessary  to  accurately  correlate  the  visit  data  to  the  DFPCM 
sections.  For  example,  the  CTMC  section  visit  count  is  a  combination  of  multiple 
lines  and  colunms  from  the  MED  302  file.  The  disparity  occurs  because  PAD  divides 
section  visits  into  subdivisions  for  their  hospital  reporting  requirements.  For  the 
Department  Chief’s  purposes,  only  the  total  visit  information  for  each  section  is 
necessary. 
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Table  VI.  MED  302  DATA  EXTRACTION  LOCATIONS 


SECTION  CODE  LOCATION  IN  MED  302  (LINE  #’s  &  COL’ 
FPC  SUM  (134  A  &  B  TO  140  A  &  B) 

CFP  SUM  (134C  TO  140C) 

EMS  SUM  (147  A  &  B) 

FSO  SUM  (148  A  &  B) 

GOC  SUM  (141  A  &  B) 

POM  1410 

CTM  SUM  (141 C,  171C,  174C,  141 F) 

FHL  SUM  (141E,  171 E,  174E) 


s) 


PRODUCTIVITY  SYSTEM 


Figure  78.  Productivity  Menu  Hierarchy  Chart 

The  visit  information  in  the  MED  302  file  can  be  extracted  for  entry 


into  the  visit  database  in  one  of  two  general  ways,  either  automatically  or  manually. 
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To  extract  the  visit  data  automatically,  an  extraction  program  can  be 
written  to  take  data  £rom  the  MED  302  spreadsheet  file  and  load  it  on  a  floppy  disk. 
Another  program  is  necessary  to  transfer  the  data  from  the  disk  into  the  department 
productivity  system’s  visit  database  in  the  correct  format. 

Manual  extraction  would  require  PAD  to  print  the  department’s  sections 
and  visit  data,  monthly,  to  a  paper  report.  The  user  of  the  department  productivity 
system  would  select  the  "Add  Visit  Data"  option  from  the  "Update  Visit  Data"  menu 
and  enter  the  visit  data  contained  in  the  printed  report  provided  by  PAD.  The  input 
screen  for  adding,  changing,  or  removing  visit  data  is  shown  in  Figure  79. 


Fiscal  Yaar 

Month 

Saction  Coda 

*  of  Visits 

■ 

■ 

■1 

■■ 

Saetlon 

Codas 

Fasilly  Fcactlea  Clinic 

FPC 

Censolldatad  Troop  Clinic 

CTM 

Ganaral  Outpatlant  Clinic 

GOC 

Fort  Bun tar  Llggatt 

FHI, 

CTMC  Family  Practlea 

crp 

Ambulanea  Saction 

AMB 

Emar^aney  Madlcal  Sarviea 

EMS 

Flight  Surgaon  Offlea 

FSO 

Prasldlo  of  Montaray 

POM 

Figure  79.  Visit  Data  Input  Screen 

Either  of  the  above  input  methods  is  technically  feasible.  However, 
there  are  tradeoffs  in  choosing  one  method  over  the  other.  The  automated  method 
eliminates  the  need  for  manual  entry  of  each  section’s  visit  data  every  month.  On  the 
other  hand,  the  amount  of  data  entry  is  relatively  small.  There  are  eight  sections  with 
visit  data  requiring  ^jproximately  11  keystrokes  for  each  section  (see  Figure  79). 
Thus,  in  any  given  month,  it  would  require  approximately  90  keystrokes  to  enter  the 
new  visit  information  into  the  database.  The  main  drawback  to  automating  the 
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information  extraction  lies  in  the  MED  302  file  itself.  PAD  created  the  spreadsheet 
file  for  their  own  use  in  creating  the  hospital’s  MED  302  report.  The  DFPCM  has  no 
control  over  PAD’S  use  of  the  spreadsheet  file.  Therefore,  any  changes  PAD  might 
make  to  the  file  would  cause  any  extraction  program  referencing  specific  lines  and 
columns  to  fail.  Other  changes  in  the  method  of  visit  data  collection  or  reporting 
would  likely  require  changes  in  the  extraction  programs.  Both  extraction  methods 
require  cooperation  and  coordination  between  the  DFPCM  and  the  PAD,  with  the 
automated  method  requiring  considerably  greater  effort. 

The  method  of  extraction  aside,  once  the  data  is  contained  in  the 
database,  the  user  can  view  the  data  by  selecting  one  of  the  outputs  described  in  the 
following  section. 

c.  Outputs 

(1)  Review  Visit  Data.  The  review  is  an  option  under  the  "Update 
Visit  Data"  menu  and  allows  the  user  to  view  the  entire  visit  database.  All  of  the 
database  fields  are  displayed  in  the  standard  review  format  described  in  Section  C.2.b., 
Review  Screens. 

(2)  Department  Monthly  Visit  Report  (see  Figwe  80).  The  monthly 
visit  report  is  a  bar  graph  showing  each  sections’  total  visits  for  the  desired  fiscal  year 
and  month.  This  report  provides  the  Department  Chief  with  a  quick  indication  of  the 
level  of  work  done  by  each  of  the  eight  sections  reporting  visit  information.  All  of 
the  visit  database  fields  are  necessary  to  create  the  monthly  visit  report. 
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The  following  numbered  items  correspond  to  the  numbers  in  Figure 


80  and  explain  the  monthly  visit  report: 

1  The  month  and  year  for  the  report. 

2  The  total  number  of  visits  (in  thousands)  for  each  clinic  is  plotted  on  the  Y- 
axis. 

3  The  eight  department  sections  are  ploned  along  the  X-axis. 


DEPARTMENT  MONTHLY  VISITS 


(D 

Number  of  Visits  (thousands) 


/air  ISM 


Figure  80.  Department  Monthly  Visit  Report 

(3)  Visit  Trend  Report  (see  Figure  81).  The  visit  trend  report  is  a 
multiple  gr^h  report  showing  fiscal  year  trends  in  patient  visits  for  each  section.  To 
simplify  viewing,  only  two  sections  are  shown  on  each  graph  resulting  in  four  graphs 


for  the  entire  report.  All  of  the  visit  database  fields  are  required  for  the  visit  trend 
rq)ort. 

The  following  numbered  items  correspond  to  the  numbers  in  Figure 
81  and  explain  the  visit  trend  report. 

1,  The  Hscal  year  of  the  report. 

2  The  number  of  visits  for  each  clinic  is  plotted  in  the  appropriate  graph  on  the 
Y-axis. 

3  Each  month  of  the  reported  fiscal  year  is  grq}hed  along  the  X-axis.  There  are 
two  sections  plotted  on  each  graph,  each  with  a  different  trend  line  style. 

(4)  Expenditure/Visit  Comparison  Report  (see  Figure  82).  The 
expenditureA'isit  comparison  report  shows  the  dollar  amount  spent  per  patient  visit.  To 
obtain  the  data  necessary  to  produce  this  report,  the  information  in  the  visit  database 
must  be  combined  with  information  from  two  of  the  databases  maintained  by  the 
budget  system:  the  APC  monthly  expenditure  database;  and  the  APC  database. 
Because  of  the  relationship  between  the  APC  and  the  Section  Code,  the  visit  database 
must  first  be  combined  with  the  APC  database  to  relate  the  visit  database  section  code 
with  the  APCs  used  in  the  budget  system.  The  resulting  combination  must  further  be 
combined  with  the  APC  monthly  expenditure  database.  This  combination  is  necessary 
to  relate  the  number  of  visits  for  a  particular  section  code  to  that  section’s  expenditures 
for  the  same  month  and  fiscal  year  desired  for  the  report.  The  three  databases  and 
their  field  relationships  are  shown  in  Figure  83. 
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$  Expended  Per  Visit 


Expenditure/Visit  Comparison 

July  1989 

(S) 


■4-  .  ■  j 

CTM 


FPC 


EMS 


GOC  CPF 


FHL 


FSO  POM 


(§)  Sections 

Figure  82.  Expenditure/Visit  Comparison 

The  combined  data  fields  necessary  to  create  the  report  are  listed 


below; 

•  Fiscal  Year. 

•  Month. 

•  Section  Code 

•  APC. 

•  Expenditure. 


Number  of  Visits. 


The  following  numbered  items  correspond  to  the  numbers  in  Figure 
82  explaining  the  comparison  report. 

X  The  month  and  fiscal  year  of  the  report. 

2  The  dollar  expenditure  per  patient  visit  is  plotted  along  the  Y-axis.  For  each 
section,  divide  the  monthly  expenditure  by  the  monthly  number  of  visits  to  arrive 
at  the  expenditure  per  visit  amount. 

3  Each  section  is  plotted  along  the  X-axis  with  a  vertical  bar  showing  the  dollar 
expenditure  per  visit. 


VISIT  DATABASE 


APC  DATABASE 


MONTHLY  EXPENDITURE  DATABASE 


Figure  83.  Productivity  and  Budget  Database  Relationships 

(5)  Department  Expenditure  and  Visit  Trend  Report  (see  Figure  84). 
The  expenditure  and  visit  trend  report  allows  the  Department  Chief  to  rapidly  assess 
the  general  direction  department  spending  is  taking  in  comparison  to  the  department’s 
workload.  The  process  for  obtaining  the  information  for  the  report  is  similar  to  that 
used  in  the  Expenditure/Visit  Comparison  report  discussed  previously.  The  same 
combined  database  fields  are  used  in  both  reports,  however,  the  calculations  for  each 
report  are  different. 
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The  foUowing  numbered  items  correspond  to  the  numbers  in  Figure 
84  and  explain  the  data  calculations  required  to  produce  the  expenditure  and  visit  trend 
report. 

1  The  fiscal  year  of  the  report. 

2  The  dollar  amoimt  of  department  expenditures  for  each  month  of  the  fiscal 
year.  Sum  the  eight  section’s  expenditure  data  for  each  month  to  obtain  the  total 
monthly  department  expenditures. 

3  The  number  of  department  visits  for  each  month  of  the  fiscal  year.  Sum  the 
eight  sections’  visit  data  for  each  month  to  obtain  the  total  monthly  department 
visits. 

4  The  dollar  amount  of  expenditures  and  the  number  of  visits  are  both  plotted 
on  the  Y-axis.  The  numbers  along  the  Y-axis  represent  both  thousands  of  dollars 
and  thousands  of  visits. 
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Figure  84.  Department  Expenditure  and  Visit  Trend  Report 


VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  PROJECT  SYNOPSIS 

We  began  our  information  systems  development  project  for  Silas  B.  Hays  by 
studying  the  current  literature  on  information  systems  development  and  hospital 
infoimation  systems.  The  findings  of  this  literature  research  were  presented  in  Chapter 
n.  In  summary,  there  were  a  multitude  of  systems  development  methodologies  from 
which  to  choose.  We  determined  that  a  combination  of  two  corrunonly  used 
methodologies,  a  traditional  systems  development  life  cycle  and  a  prototyping 
methodology,  would  best  fit  our  needs.  The  life  cycle  methodology  provided  us  with 
the  structured  techniques  to  develop  the  proposed  information  system,  while  prototyping 
allowed  us  to  quickly  develop  the  user  interfaces  necessary  to  rapidly  identify  user 
requirements.  Through  research,  we  determined  that  the  critical  nature  of  the  health 
care  environment  influences  the  information  systems  used  by  hospitals.  There  exists 
a  dichotomy  between  the  goals  and  objectives  of  hospital  administrators  and  health  care 
providers.  This  dichotomy  influences  the  way  in  which  information  systems  are  used 
to  meet  these  differing  objectives.  Additionally,  the  resource  constraints  within  the 
hospital  create  pressures  when  considering  the  use  of  information  systems  by  both 
administrators  and  health  care  providers.  This  was  particularly  true  in  the  case  of  the 
DFPCM,  whose  Chief  is  both  a  health  care  provider,  and  by  necessity,  an  administrator. 

We  conducted  interviews  with  senior  hospital  managers  to  obtain  a  clear  problem 
definition  and  to  focus  our  research.  The  feedback  from  these  discussions  directed  us 
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to  the  Department  of  Family  Practice  and  Community  Medicine  (DFPCM).  This  large, 
multi-service  department  greatly  affects  overall  hospital  operations.  Chjq)ter  HI 
provided  a  detailed  look  at  the  DFPCM:  its  structure  and  its  current  information 
systems.  The  Chief  of  the  DFPCM  commands  more  than  150  people  and  manages  an 
annual  budget  of  nearly  half  a  million  dollars.  In  initial  discussions  with  the  Chief, 
he  identified  and  prioritized  his  most  critical  management  concerns:  budget,  equipment, 
persotmel,  scheduling,  patient  satisfaction,  and  productivity.  The  information  systems 
relating  to  these  six  management  areas  became  the  subject  of  om  research. 

Discussions  with  the  Department  Chief  and  his  senior  department  personnel 
helped  us  identify  their  requirements  for  infonnation  in  each  of  the  six  areas.  In 
analyzing  their  needs,  and  comparing  the  needs  with  the  current  information  systems, 
we  were  able  to  propose  improvements  to  the  systems  in  Chapter  IV.  Those 
improvements  included:  the  use  of  databases;  simpler  data  collection;  automated  data 
manipulations  (in  some  cases);  concise,  summary  reports;  grq}hical  reports;  trend 
analysis  capabilities;  and  improved  automated  user  interfaces  (where  applicable). 

The  improvements  proposed  in  Chapter  IV  were  prototyped  in  Ch^ter  V  to 
produce  a  detailed  requirements  analysis  for  the  six  information  systems  in  the  DFPCM. 
The  databases,  user  interface  screens,  and  outputs  of  the  systems  were  designed  to  help 
us  pinpoint  the  user’s  requirements.  The  Department  Chief  and  other  department 
managers  provided  feedback,  allowing  us  to  tailor  the  prototyped  models  to  their 
specifications.  Time  constraints  allowed  only  one  iteration  of  the  prototyping  process. 
Further  iterations  would  further  enhance  the  requirements  analysis  presented  in  Chapter 
V. 


192 


The  general  conclusions  resulting  from  our  research  are  presented  in  the  following 
section.  The  recommendations  for  follow  on  thesis  study  are  discussed  in  the  last 
section  of  this  chapter. 

B.  CONCLUSIONS 

The  requirements  analysis  presented  in  this  thesis  is  the  first  step  in  the 
development  life  cycle  for  the  DFPCM  information  system.  With  the  existing 
information  system  defined  and  the  requirements  identified  and  analyzed,  the  system 
can  be  fully  designed,  constructed,  and  implemented  to  meet  the  needs  of  the  targeted 
department  users. 

The  process  of  requirements  analysis  is  a  complex  task  which  if  done  poorly  will 
likely  result  in  a  substandard  system  development.  The  complexity  of  this  task  leads 
to  many  difficulties  which  the  analysts  must  face  during  the  development  process. 

Identifying  the  system’s  target  audience  and  obtaining  a  clear  problem  definition 
are  essential  first  steps  in  the  process.  Without  a  clear  understanding  of  the  intended 
users  and  their  related  problems,  the  analyst’s  energies  and  resources  are  wasted  on 
unimportant  or  non-existent  requirements.  Starting  on  the  right  track  early  in  the 
process  requires  the  involvement  of  senior  management  to  obtain  the  input  from  those 
personnel  who  are  in  a  position  to  identify  problem  areas.  Once  involved  in  the  thesis 
study,  the  senior  managers  at  Silas  B.  Hays  were  quick  to  identify  the  DFPCM  as 
potential  benefitors  of  an  improved  information  system.  Frequent  and  early  interactions 
with  the  users  were  critical  in  identifying  the  detailed  requirements  of  each  of  the 
subsystems  presented. 


Selecting  the  "best"  development  methodology  is  the  next  hurdle  in  the 
development  process.  Given  the  large  number  of  methodologies  in  existence,  it  is 
doubtful  there  is  one  "best"  method.  Rather,  the  analyst  must  choose  the  methodology 
most  suited  to  the  task  at  hand,  with  which  he  has  the  most  experience,  or  simply,  one 
which  he  feels  most  comfoitable  using.  Eiecisions  such  as  whether  to  use  data  flow 
diagrams  or  user  concept  diagrams  depends  on  a  number  of  factors,  the  bottom  line 
being  whether  or  not  the  ,uialyst  can  use  the  method  effectively  to  build  a  high  quality 
system  acceptable  to  the  intended  users. 

The  use  of  prototyping  in  the  early  stages  of  system’s  development  was  shown 
to  be  beneficial  in  identifying  the  inputs,  interfaces,  and  output  requirements  desired 
by  the  intended  users.  Using  separate  software  packages  to  design  the  various 
prototypes  was  time  consuming  and  did  not  allow  direct  integration  of  the  input  and 
output  prototype  programs.  The  use  of  a  dedicated,  integrated  prototype  tool  which 
does  all  of  these  processes  could  have  greatly  enhanced  our  productivity  in  prototype 
development. 

The  project  management  of  the  system  development  is  critical  for  an  efficient  and 
effective  process.  The  division  of  labor,  coordination  of  effort,  and  teamwork  were 
important  issues  throughout  the  project.  When  these  factors  are  missing  or  inadequate 
in  project  development,  schedules  slip  and  resources  are  wasted. 

An  important  influence  in  the  development  project  at  Silas  B.  Hays  is  the 
complexity  of  the  computer  systems  in  place  at  the  hospital.  The  lack  of  integration 
of  these  systems  firustrates  the  development  of  an  information  system  and  ultimately 
causes  more  work  for  the  users  in  duplicating  the  data  collection  and  reporting  efforts. 
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The  integrated  Composite  Health  Care  System  planned  for  implementation  in  the  early 
1990s  does  not  answer  the  needs  of  the  department  managers  today.  The  new  Director 
of  Information  Management  at  Silas  B.  Hays  has  begun  planning  for  solving  the 
integration  problems  using  networking  technology. 

A  valuable  lesson  learned  during  the  writing  of  this  thesis  was  that  the  use  of 
automation  is  not  always  appropriate  in  every  part  of  an  information  system.  In  some 
cases,  automation  would  actually  create  more  work  in  relation  to  any  benefits  gained. 
With  the  intense  workload  of  the  department’s  personnel,  every  effort  must  be  made 
to  reduce  the  amount  of  work  required  while  providing  the  best  possible  information 
to  the  department  chief. 

C.  RECOMMENDATIONS  AND  FOLLOW-ON  THESIS  WORK 

The  requirements  analysis  presented  in  this  thesis  should  be  used  to  further  design 
and  implement  a  complete  information  system  for  the  DFPCM.  The  hospital’s 
Information  Management  Division  can  use  the  prototype  program  listings,  and  input  and 
output  examples  to  develop  a  working  system  using  the  software  packages  currently 
available  in  the  hospital,  or  they  can  use  the  requirements  to  justify  purchasing  or 
developing  other  software  as  required  to  implement  the  systems.  Possible  follow  on 
thesis  work  in  this  area  includes  designing,  constructing,  and/or  implementing  an 
information  system  from  a  previously  developed  requirements  analysis.  Evaluating  and 
selecting  software  and  hardware  alternatives,  including  thorough  economic  analyses, 
provide  additional  possibilities  for  future  research. 

The  information  which  could  be  provided  to  hospital  managers  by  a  completed 
system  may  be  useful  to  other  hospital  departments.  Follow  on  thesis  work  could 
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involve  expanding  the  initial  requirements  analysis  of  this  thesis  to  other  departments 
or  the  hospital  as  a  whole. 

Additional  follow-on  thesis  work  include:  research  into  the  design  of  an 
optimization  model  for  the  doctor  scheduling  process  and  further  research  into  the 
doctor  productivity  issues  discussed  in  Chapter  IV. 

At  a  minimum,  the  analysis  contained  in  this  thesis  can  be  used  by  senior 
hospital  managers  to  identify  the  shortcomings  of  the  existing  information  systems  in 
providing  department  managers  with  the  high  quality  information  they  require  to 
successfully  manage  the  many  resources  needed  to  accomplish  their  missions. 
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APPENDIX  A.  DATA  DICTIONARY 


BUDGET  DATABASE  FILES 


APC  FILE 


FIELD 

NAME 

FIELD 

TYPE 

APC 

CHARACTER 

SECTION 

CHARACTER 

SECTCODE 

CHARACTER 

POC 

CHARACTER 

TELEPHONE 

NUMERIC 

STATUS 

CHARACTER 

FIELD 

NAME 

FIELD 

TYPE 

APC 

CHARACTER 

FY 

NUMERIC 

QUARTER 

NUMERIC 

ALLOCATION 

MONEY 

FIELD 

LENGTH/ 

DECIMALS 


DESCRIPTION 
OF  FIELD 


ACCOUNT  PROCESSING  CODE  :  FORMAT  A999 


NAME  OF  SECTION  ASSIGNED  TO  APC  CODE 


SECTION  CODE 


POINT  OF  CONTACT 


TELEPHONE  NUMBER  :  FORMAT  (999)999-9999 


STATUS  CODE  [  A; ACTIVE,  I : INACTIVE  ] 


QTRALLOC  FILE 


FIELD 

LENGTH/ 

DECIMALS 


DESCRIPTION 
OF  FIELD 


ACCOUNT  PROCESSING  CODE 


FISCAL  YEAR  OF  ALLOCATION 


QUARTER  WITHIN  THE  FISCAL  YEAR 


BUDGET  ALLOCATION  FOR  THE  QUARTER 


MOEXP  FILE 

FIELD 

NAME 

FIELD 

TYPE 

FIELD 

LENGTH/ 

DECIMALS 

DESCRIPTION 

OF  FIELD 

APC 

CHARACTER 

4 

0 

ACCOUNT  PROCESSING  CODE 

MONTH 

NUMERIC 

2 

0 

MONTH  THE  EXPENSE  OCCURRED 

FY 

NUMERIC 

2 

0 

FISCAL  YEAR  OF  EXPENDITURE 

QUARTER 

NUMERIC 

mm 

0 

CC»4PUTED,  BASED  ON  MONTH 

EXPENSES 

MONEY 

11 

2 

DOLLARS  EXPENDED  FOR  MONTH 
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EQUIPMENT  DATABASE  FILES 


EQUIP  FILE 

FIELD 

NAME 

FIELD 

TYPE 

FIELD 

LENGTH/ 

DECIMALS 

DESCRIPTION 

OF  FIELD 

EQCODE 

NUMERIC 

7 

2 

EQUIPMENT  REQUEST  NUMBER  (GENERATED) 

SECTCODE 

CHARACTER 

3 

0 

SECTION  CODE 

REQDATE 

DATE 

8 

0 

DATE  OF  ORIGINAL  REQUEST 

DESCRIPT 

CHARACTER 

20 

0 

DESCRIPTIVE  NAME  OF  EQUIPMENT  NEEDED 

REQTYPE 

CHARACTER 

4 

0 

TYPE  OF  EQUIPMENT  REQUEST,  i.e.  CEEP 

PRIORITY 

NUMERIC 

2 

II 

PRIORITY  OF  REQUEST  WITHIN  TYPE  OF  EQUIP 

URGCODE 

NUMERIC 

1 

0 

URGENCY  OF  REQUEST  (  0  TO  4  ) 

QTY 

NUMERIC 

3 

0 

QUANTITY  OF  EQUIPMENT  NEEDED 

UNITPRICE 

MONEY 

9 

2 

PRICE  PER  UNIT  OF  EQUIPMENT  REQUESTED 

EXTPRICE 

MONEY 

10 

2 

EXTENDED  PRICE  OF  EQUIPMENT 

STATUS 

CHARACTER 

2 

0 

STATUS  OF  REQUEST  IN  CODED  FORM 

CC»«MENTS 

CHARACTER 

20 

0 

COIMENTS  ON  REQUEST 

EQHIST  FILE 

FIELD 

NAME 

FIELD 

TYPE 

FIELD 

LENGTH/ 

DECIMALS 

DESCRIPTION 

OF  FIELD 

SECTCODE 

CHARACTER 

3 

0 

SECTION  CODE 

DESCRIPT 

CHARACTER 

20 

m 

DESCRIPTIVE  NAME  OF  EQUIPMENT  NEEDED 

REQTYPE 

CHARACTER 

4 

0 

TYPE  OF  EQUIPMENT  REQUEST,  i.e.  CEEP 

QTY 

NUMERIC 

3 

0 

QUANTITY  OF  EQUIPMENT  NEEDED 

EXTPRICE 

MONEY 

10 

2 

EXTENDED  PRICE  OF  EQUIPMENT 

REQDATE 

DATE 

8 

0 

DATE  OF  ORIGINAL  REQUEST 

XFERDATE 

DATE 

8 

0 

DATE  TRANSFERRED  TO  HISTORICAL  FILE 

NUMERIC 

3 

0 

MONTHS  IT  TOOK  TO  COMPLETE  REQUEST 

COMMENTS 

CHARACTER 

20 

0 

COMMENTS  ON  REQUEST 

PERSONNEL  DATABASE  FILES 


PERSONNEL  FILE 

FIELD 

NAME 

FIELD 

TYPE 

FIELD 

LENGTH/ 

DECIMALS 

DESCRIPTION 

OF  FIELD 

IDCODE 

CHARACTER 

5 

II 

PERSONNEL  IDENTIFICATION  CODE 

LNAME 

CHARACTER 

20 

0 

LAST  NAME 

FNAME 

CHARACTER 

15 

II 

FIRST  NAME,  MIDDLE  INITIAL 

RANK 

CHARACTER 

3 

0 

RANK  OF  PERSON 

BRANCH 

CHARACTER 

2 

0 

BRANCH  OF  PERSON 

MOS 

CHARACTER 

5 

0 

MILITARY  OCCUPATIONAL  SPECIALTY  CODE 

STATUS 

NUMERIC 

1 

0 

RESIDENCY  CODE  (IF  IN  RESIDENCY  PROGRAM) 

ALOSS 

DATE 

8 

II 

ANTICIPATED  DATE  OF  LOSS 

ARRDATE 

DATE 

8 

0 

ARRIVAL  DATE  IN  DEPARTMENT 

NUMERIC 

3 

0 

TDA  PARAGRAPH  NUMBER  ASSIGNED  TO  PERSON 

CHARACTER 

3 

0 

TDA  LINE  NUMBER  ASSIGNED  TO  PERSON 

NUMERIC 

2 

II 

TDA  POSITION  NUMBER  ASSIGNED  TO  PERSON 

PERSONAL  FILE 

FIELD 

NAME 

FIELD 

TYPE 

FIELD 

LENGTH/ 

DECIMALS 

DESCRIPTION 

OF  FIELD 

IDCODE 

CHARACTER 

5 

0 

PERSONNEL  IDENTIFICATION  CODE 

ADDRESS 

CHARACTER 

20 

0 

PERSON'S  ADDRESS  (HOME) 

CITY 

CHARACTER 

20 

0 

CITY  (HOME) 

STATE 

CHARACTER 

2 

0 

STATE  (HOME) 

ZIPCODE 

NUMERIC 

9 

0 

ZIPCODE  +  4  (HOME) 

WIFE 

CHARACTER 

10 

II 

WIFE'S  NAME 

CHILDREN 

CHARACTER 

25 

0 

CHILDREN'S  FIRST  NAMES  AND  AGES 

TELEPHONE 

NUMERIC 

9 

0 

TELEPHONE  NUMBER  WITH  AREA  CODE  (HOME) 

DOR 

DATE 

8 

0 

DATE  OF  RANK 

COMMENTS 

CHARACTER 

30 

0 

COMMENTS  (PERSONAL) 
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FIELD 

NAME 


FIELD 

TYPE 


FIELD 

LENGTH/ 

DECIMALS 


TDA  FILE 


DESCRIPTION 
OF  FIELD 


NUMERIC 

3 

■ 

TDA  PARAGRAPH  NUMBER 

CHARACTER 

3 

0 

TDA  LINE  NUMBER 

NUMERIC 

2 

0 

TDA  POSITION  NUMBER 

CHARACTER 

20 

0 

OFFICIAL  JOB  TITLE  AS  STATED  ON  TDA 

APC 

CHARACTER 

4 

0 

ACCOUNT  PROCESSING  CODE 

CHARACTER 

2 

0 

AUTHORIZED  BRANCH  OF  SERVICE 

CHARACTER 

2 

■ 

AUTHORIZED  GRADE  (RANK) 

CHARACTER 

6 

■ 

MILITARY  OCCUPATIONAL  SPECIALTY  CODE 

AUTH 

CHARACTER 

1 

■ 

AUTHORIZED  SLOT  CODE  (FROM  TDA) 

ABSENCE  FILE 

— 

FIELD 

NAME 

FIELD 

TYPE 

FIELD 

LENGTH/ 

DECIMALS 

DESCRIPTION 

OF  FIELD 

IDCODE 

CHARACTER 

5 

0 

PERSONNEL  IDENTIFICATION  CODE 

FY 

NUMERIC 

2 

II 

FISCAL  YEAR  OF  ABSENCE  REQUEST 

TYPE 

CHARACTER 

1 

0 

TYPE  OF  ABSENCE  (CODED) 

START 

DATE 

8 

0 

START  DATE  OF  ABSENCE 

END 

DATE 

8 

0 

END  DATE  OF  ABSENCE 

DURATION 

NUMERIC 

3 

0 

CALCULATE  (START  DATE  -  END  DATE) 

COMMENTS 

CHARACTER 

30 

II 

COMMENTS  ABOUT  ABSENCE  REQUEST 

CME ALLOC  FILE 

FIELD 

NAME 

FIELD 

TYPE 

FIELD 

LENGTH/ 

DECIMALS 

DESCRIPTION 

OF  FIELD 

FY 

NUMERIC 

2 

0 

FISCAL  YEAR  OF  CME  FUNDS  ALLOCATION 

ALLOCATION 

MONEY 

11 

2 

CME  FUNDS  ALLOCATION  FOR  THE  FY 
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CMEPEQ  FILE 


FIELD 

NAME 


IDCODE 


FIELD 

TYPE 


FIELD 

LENGTH/ 

DECIMALS 


DESCRIPTION 
OF  FIELD 


PERSONNEL  IDENTIFICATION  CODE 


FISCAL  YEAR  OF  REQUEST 


TYPE  OF  CME  REQUEST  (ONE  DIGIT  CODE) 


START  DATE  OF  CME  TRAVEL 


ENDING  DATE  OF  CME  REQUEST 


CALCULATED  (END  DATE  -  START  DATE) 


LOCATION  OF  REQUESTED  CONFERENCE 


PURPOSE  OF  (aiE  TRAVEL 


MODE  OF  TRAVEL  (CODED) 


COST  OF  TRAVEL 


PER  DIEM  COSTS  OF  TRAVEL 


REGISTRATION  FEES 


REIMBURSABLE  EXPENSES 


TRAVELCOST+PERDIEM+REGFEE+REIMB 


COST  CODE  (A-ACTUAL  OR  E-ESTIMATED) 


ABSENCE  FILE 


FIELD 

NAME 


IDCODE 


DURATION 


COMMENTS 


FIELD 

TYPE 


FIELD 

LENGTH/ 

DECIMALS 


CHARACTER 


DESCRIPTION 
OF  FIELD 


PERSONNEL  IDENTIFICATION  CODE 


FISCAL  YEAR  OF  ABSENCE  REQUEST 


TYPE  OF  ABSENCE  (CODED) 


START  DATE  OF  ABSENCE 


END  DATE  OF  ABSENCE 


CALCULATE  (START  DATE  -  END  DATE) 


COMMENTS  ABOUT  ABSENCE  REQUEST 
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SATISFACTION  DATABASE  FILE 


SURVEY  FILE 


FIELD 

NAME 

FIELD 

TYPE 

FIELD 

LENGTH/ 

DECIMALS 

DESCRIPTION 

OF  FIELD 

MONTH 

NUMERIC 

2 

0 

MONTH  SURVEY  TAKEN 

YEAR 

NUMERIC 

2 

II 

YEAR  SURVEY  TAKEN 

SECTCODE 

CHARACTER 

3 

m 

SECTION  CODE  (FROM  SURVEY) 

DOCTORNAME 

CHARACTER 

20 

II 

DOCTOR'S  LAST  NAME,  FIRST  NAME,  MI 

APPTDAYS 

NUMERIC 

1 

0 

NUMBER  OF  DAYS  TO  GET  APPOINTMENT 

ACCAPPT 

NUMERIC 

1 

0 

ACCEPTABILITY  OF  DAYS  TO  GET  APPOINTMENT 

RECORDS 

NUMERIC 

1 

0 

WERE  MEDICAL  RECORDS  READY? 

HAITTIME 

NUMERIC 

1 

0 

WAITING  TIME  SCORE 

ACCWAIT 

NUMERIC 

1 

II 

ACCEPTABILITY  OF  WAITING  TIME  SCORE 

RECEPT 

NUMERIC 

1 

0 

COURTESY  OF  RECEPTIONIST  SCORE 

NURSE 

NUMERIC 

1 

0 

COURTESY  OF  NURSES  SCORE 

DOCTORS 

NUMERIC 

1 

0 

COURTESY  OF  DOCTORS  SCORE 

EXPLAIN 

NUMERIC 

1 

II 

EXPLANATIONS  OF  PROCEDURES  SCORE 

TIMESPENT 

NUMERIC 

1 

0 

ADEQUACY  OF  TIME  SPENT  WITH  DOCTOR  SCORE 

CLEAN 

NUMERIC 

1 

0 

CLEANLINESS  OF  CLINIC  SCORE 

SATIS 

NUMERIC 

1 

0 

GENERAL  SATISFACTION  SCORE 

PATC(»®1ENT 

CHARACTER 

■■ 

II 

ARE  THERE  PATIENT  CC»1MENTS  TO  ENTER? 

CC»1MENTS 

MEMO 

10 

0 

COMMENTS  MEMO  FIELD 

SCORE  ;  NUMBER  MARKED  ON  PATIENT'S  SURVEY  QUESTIONNAIRE 
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PR0DT7CTIVITY  DATABASE  FILE 


VISIT  FILE 

FIELD 

FIELD 

FIELD 

DESCRIPTION 

NAME 

TYPE 

LENGTH/ 

DECIMALS 

OF  FIELD 

FY 

NUMERIC 

2 

0 

FISCAL  YEAR  OF  VISIT  INFORMATION 

MO 

NUMERIC 

2 

Di 

MONTH  OF  VISIT  INFORMATION 

SECTCODE 

CHARACTER 

3 

0 

SECTION  CODE 

VISITS 

NUMERIC 

4 

0 

NUMBER  OF  VISITS  FOR  SECTION  CODE 
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APPENDIX  B.  DISPLAY  SCREENS 


LIST  OF  SCREENS 

ABSENCE  SCREEN  FILE 

ARC  SCREEN  FILE 

CHOICE  SCREEN  FILE 

CMEALLOC  SCREEN  FILE 

CMEREQ  SCREEN  FILE 

CONFIRM  SCREEN  FILE 

DELCMERE  SCREEN  FILE 

DELLEAVE  SCREEN  FILE 

DELMOEXP  SCREEN  FILE 

DELQALLO  SCREEN  FILE 

EQUIPMENT  SCREEN  FILE 

EQUIPMENT  UPDATE  FROM  RIR  SCREEN  FILE 

MOEXP  SCREEN  FILE 

OCCUPIED  SCREEN  FILE 

PERRIR_B  SCREEN  FILE 

PERSON  SCREEN  FILE 

POSITION  SCREEN  FILE 

QTRALLOC  SCREEN  FILE 

SOCIAL  SCREEN  FILE 

SURVEY  SCREEN  FILE 

TDA  SCREEN  FILE 

TDAINPUT  SCREEN  FILE 

UPCMEREQ  SCREEN  FILE 


ABSENCE  SCREEN  FILE 

Update  and  change  the  absence  information  in  the  Personnel  Database. 


a 

0. 

21 

SAY 

"UPDATE  LEAVE  OR  ABSENCE  REQUEST" 

9 

3, 

4 

SAY 

"This  is  the  Fiscal  Year* 

9 

3, 

28 

SAY 

ABSENCE->FY  PICTURE  "99" 

e 

3, 

31 

SAY 

"Leave  or  Absence 

request  for  ID  CODE" 

9 

3, 

€8 

SAY 

ABSENCE->IDCODE 

PICTURE  "I9999* 

9 

6, 

23 

SAY 

"Type  of  Request" 

9 

6, 

46 

GET 

ABSENCE->TYPE  PICTURE  "!’ 

9 

8, 

4 

SAY 

*L.. Regular  Leave 

E.. Emergency  Leave 

9 

9, 

4 

SAY 

"P . .Permissive  TDY 

C .. Convalescent  Leave 

9 

13, 

11 

SAY 

"Starting  Date" 

9 

13, 

26 

GET 

ABSENCE->START 

9 

13, 

38 

SAY 

"Ending  Date" 

9 

13, 

51 

GET 

ABSENCE->END 

9 

15, 

26 

SAY 

"Duration" 

9 

15, 

35 

SAY 

ABSENCE->DURATION 

PICTURE  "999" 

9 

15, 

39 

SAY 

"days" 

9 

18, 

13 

SAY 

"COMMENT" 

e 

18, 

25 

GET 

ABSENCE->COMMENT 

FUNCTION  ’!’ 

9 

2, 

1 

TO 

4,  75 

9 

7, 

2 

TO  10,  72 

T.. Other  TDY,  not  CME" 
O. .Other" 


APC  SCREEN  FILE 


Update  and  change  the  Account  Processinc  Code  infcrmation  In  the  Piidcet  Database. 


8 

2, 

23 

SAY 

0 

2, 

44 

SAY 

0 

5, 

8 

SAY 

0 

5, 

20 

GET 

0 

5, 

48 

SAY 

0 

5, 

63 

GET 

0 

8, 

20 

SAY 

0 

8, 

38 

GET 

0 

11, 

20 

SAY 

0 

11, 

38 

GET 

0 

14, 

31 

SAY 

0 

15, 

30 

SAY 

"APC  Code  Entered  ->" 

APC->APC  FUNCTION  "R"  PICTURE  "A-PPP" 
"SECTION" 

APC->SECTION 
"Section  Code" 

APC->S_CODE 
"Point  of  Contact" 

APC->POC 

"Telephone  Number’ 

APC->TELEPHONE  PICTURE  " (999) -999-9999’ 
"Sec" 

"SECTION  CODES" 
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0 

16, 

4 

SAY 

"Family  Practice  Clinic 

FPC 

Consolidated  Troop  Clinic 

CTM" 

0 

17, 

4 

SAY 

"General  Outpatient  Clinic 

GOC 

Fort  Hunter  Liggett  Clinic 

FHL" 

a 

19, 

4 

.'AY 

"CTMC-Famlly  Practice 

CFP 

Ambulance  .'ecrion 

AMB" 

0 

19, 

4 

SAY 

"Emergency  Medical  Service 

EMS 

Flight  Surgeon  Office 

FSO" 

0 

20, 

4 

SAY 

"Presidio  of  Monterey 

POM 

Department 

DEP" 

0 

1, 

1 

TO 

13,  78  DOUBLE 

0 

3, 

2 

TO 

3,  77 

0 

14, 

1 

TO 

21,  78 

CHOICE  SCREEN  FILE 

Generic  user  selection  format  for  the  Personnel  Database. 

e  6,0  TO  11,  79  DOUBLE 
0  7,10  SAY  "ENTER  YOUR  CHOICE" 

0  8,10  SAY  "1.  MOVE  THE  OLD  PERSON  TO  EXCESS  AND  THE  HEW  PERSON  INTO  THE  SLOT" 

0  9,10  SAY  "2.  PLACE  THE  PERSON  YOU  ARE  WORKING  WITH  INTO  THIS  POSITION  AS  EXCESS  (  OVERSTPENGTH, 
POSITION  CODE  -  99)" 

0  10,10  SAY  "3.  TRY  ANOTHER  POSITION  " 

0  7,28  GET  ANSWER  PICTURE  "9"  RANGE  1,3 


CMEALLOC  SCREEN  FILE 

Update  and  change  the  Continuing  Medical  Information  funds  allocation  In  Personnel  Database. 


0 

1. 

28 

SAY 

"UPDATE  CME  ALLOCATION" 

0 

5, 

9 

SAY 

"THE  CME  ALLOCATION  FOR  FISCAL  YEAR 

0 

5, 

44 

SAY 

CMEALLOC->FY 

0 

5, 

47 

SAY 

"SHOULD  BE  $■ 

0 

5, 

59 

GET 

CMEALLOC->ALLOCATION 

0 

3, 

5 

TO 

7,  73  DOUBLE 

CMEREQ  SCREEN  FILE 

Update  and  change  the  CME  request  information  In  the  Personnel  Database. 

0  1,  2  SAY  "SUBJECT:  APPLICATION  FOR  CONFERENCE/MISSION  TRAVEL  IN  FISCAL  YEAR" 

0  1,  68  SAY  M_FY  PICTURE  "99" 

0  3,  0  SAY  "1.  Type  of  Travel  Requested . " 

0  3,  34  GET  CMEREQ->TYPE  PICTURE  •!* 

0  4,  3  SAY  "C-Conference/Meeting  Travel  G-General  Mission  Travel  B-Board  Certif icatio" 

0  6,  0  SAY  "2.  ID  CODE  of  person  requesting  the  travel  is* 

0  6,  46  SAY  M  IDCODE  PICTURE  "19999" 

0  6,  52  SAY 

0  8,  0  SAY  "4.  Purpose  of  Travel  is" 

0  8,  24  GET  CMEREQ->PURPOSE 

0  8,  45  SAY  ".  5.  Registration  Fee  S" 

0  8,  71  GET  CMEREQ- >REGFEE 

0  10,  0  SAY  "6.  Destination" 

0  10,  16  GET  CMEREQ->LOCATION 
0  10,  42  SAY  "Mode  of  Travel  is" 

0  10,  60  GET  CMEREQ- >TVLMODE 

0  11,  42  SAY  "F-FLY,  G-GOVT  VEH,  P-POV,  O-OTHER" 

0  13,  0  SAY  "8.  Leave  Dates  Starting  Date" 

0  13,  31  GET  CMEREQ->START 
0  13,  41  SAY  "Ending  Date" 

0  13,  53  GET  CMEREQ->END 
0  14,  3  SAY  "Duration" 

0  14,  14  SAY  CMEREQ->DURATION 
0  14,  19  SAY  "days" 

0  16,  0  SAY  "13.  TRAVEL  COST  S" 

0  16,  18  GET  CMEREQ->TRAVELCOST 
0  16,  29  SAY  "PER  DIEM  COST  $" 

0  16,  44  GET  CMEREQ->PERDIEM 
0  16,  56  SAY  "REIMBURSABLES  $" 

0  16,  71  GET  CMEREQ->REIMB 
0  18,  17  SAY  "TOTAL  COST  OF  TRAVEL  $" 

0  18,  40  SAY  CMEREQ->TOTALCOST 
0  20,  12  SAY  "EXPENSES  REFLECT  THE" 

IF  C_CODE  -  "A" 

0  20,  33  SAY  "ACTUAL  COST  OF  TRAVEL" 

ELSE 

0  20,  33  SAY  "ESTIMATED  COST  OF  TRAVEL" 
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ENDIF 

e  0,  0  TO  2,  79 
9  I",  10  TO  21,  ?S 


CONFIRM  SCREEN  FILE 


G*n«rlc  confirmation  acraen  for  the  Personnel  Database. 

e  4,0  SAY  MESSAGE 
0  6,0  TO  9,79  DOUBLE 
0  7,5  SAY  'Last  Name:  •+LNAME 
0  7,35  SAY  "First  Name:  •+FNAME 
0  8,5  SAY  "Rank:  •+RANK 
0  8,35  SAY  "Branch:  "+BRANCH 
77  CHR(7) 

0  15,0 

WAIT  "PRESS  RETURN  TO  CONTINUE ..." 


DELCMERE  SCREEN  FILE 


Special  delete  CME  request  information  screen  in  Personnel  DatahasB . 


0 

1, 

2 

SAY 

0 

1, 

68 

SAY 

1 

9 

3, 

0 

SAY 

0 

3, 

34 

SAY 

0 

4, 

3 

SAY 

0 

6. 

0 

SAY 

9 

6, 

46 

SAY 

0 

6, 

52 

SAY 

9 

8, 

0 

SAY 

g 

8, 

24 

SAY 

9 

8, 

45 

SAY 

0 

8, 

71 

SAY 

0 

10, 

0 

SAY 

0 

10, 

16 

SAY 

0 

10, 

42 

SAY 

" 

0 

10, 

60 

SAY 

0 

11, 

42 

SAY 

0 

13, 

0 

SAY 

0 

13, 

31 

SAY 

0 

13, 

41 

SAY 

0 

13, 

53 

SAY 

0 

14, 

3 

SAY 

0 

14, 

14 

SAY 

0 

14, 

19 

SAY 

0 

16, 

0 

SAY 

0 

16, 

18 

SAY 

9 

16, 

29 

SAY 

0 

16, 

44 

SAY 

0 

16, 

56 

SAY 

0 

16, 

71 

SAY 

0 

18, 

17 

SAY 

0 

18, 

40 

SAY 

T( 

0 

20, 

17 

SAY 

■1 

GET 

1 

0 

0, 

0 

TO 

2 

0 

19, 

10 

TO  21 

SUBJECT:  DELETE  APPLICATION  FOP  CONFEPENCE/MISSION  TRAVEL  IN  FISCAL  YEAP." 
M  FY  PICTURE  *99^ 


CMEREQ->TYPE  PICTURE  * ! • 
C-Conference/Meetlng  Travel 


G-General  Mission  Travel  B-Board  Certif icatio" 


CMEREQ->IDCODE  PICTURE  •!9999* 

m 

4.  Purpose  of  Travel  Is" 

CMEREQ->PURPOSE 

.  5.  Registration  Foe  $" 

CMEREQ->REGFEE 

6.  Destination" 

CMEREQ->LOCATION 
Mode  of  Travel  Is" 
CMEREQ->TVLMODE 


8.  Leave  Dates 

CMEREQ->START 

Ending  Date" 

CMEREQ->END 

Duration" 

CMEREQ->DURAT10N 


13.  TRAVEL  COST  S" 

CMEREQ->TRAVELCOST 

PER  DIEM  COST  S" 

CMEREQ->PERDIEM 

REIMBURSABLES  S" 

CMEREQ->REIMB 

TOTAL  COST  OF  TRAVEL 


MAYBE  PICTURE 
,  79 
,  58 


Starting  Date" 


DELLEAVE  SCREEN  FILE 


Special  delete  Absence  Information  screen  for  the  Personnel  Database. 


0 

0, 

21 

SAY 

0 

3, 

4 

SAY 

0 

3, 

28 

SAY 

0 

3, 

31 

SAY 

9 

3, 

68 

SAY 

0 

6, 

23 

SAY 

9 

6, 

46 

SAY 

"UPDATE  LEAVE  OR  ABSENCE  REQUEST" 

"This  Is  the  Fiscal  Year" 

ABSENCE->FY  PICTURE  "99" 

"Leave  or  Absence  request  for  ID  CODE" 
ABSENCE->IDCODE  PICTURE  "!9999’ 

"Type  of  Request" 

ABSENCE->TYPE  PICTURE  "!" 
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@  8,  4  SAY  “L.. Regular  Leave  E .. Emergency  Leave  T.. Other  TDY,  not  CME" 

@  9,  4  SAY  "P . .Permiasive  TPY  C . . Con . a leacent  Leave  O.. Other" 

(J  1’,  n  PAY  "Ptarrlng  Date* 

0  13,  26  SAY  ABSENCE->START 

0  13,  38  SAY  "Ending  Date* 

0  13,  51  SAY  ABSENCE->END 
0  15,  26  SAY  "Duration" 

0  15,  35  SAY  ABSENCE->DURATION  PICTOPE  *999" 

0  15,  39  SAY  "daya" 

0  18,  13  SAY  "COMMENT" 

0  18,  25  SAY  ABSENCE->COMMENT 
02,  1  TO  4,  75 

0  7,  2  TO  10,  72 

0  22,  17  SAY  "DO  YOU  WANT  TO  DELETE  THIS  PECOPD"; 

GET  MAYBE  PICTURE  " ! " 

0  21,  10  TO  23,  58 


DELMOEXP  SCREEN  FILE 


Special  delete  Monthly  Expenditure  format  for  the  Budget  Databaae. 

0  2,  20  SAY  "Delete  thia  Monthly  Expenditure" 

0  5,  26  SAY  "APC  Code" 

0  5,  38  SAY  MOEXP->APC  FUNCTION  "!"  PICTURE  "A###" 

0  7,  26  SAY  "Month" 

0  7,  38  SAY  MOEXP->MONTH 

0  9,  26  SAY  "Expenaea" 

0  9,  38  SAY  MOEXP->EXPENSES 

0  4,  15  TO  10,  56  DOUBLE 

0  18,  14  TO  20, 59 

0  19,  19  SAY  "Delete  thia  Record?  (Y/N) 

GET  Maybe  PICTURE  '!" 


DELQALLO  SCREEN  FILE 

Special  delete  quarterly  allocation  format  for  the  Budget  Databaae. 

0  3,  19  SAY  "Delete  the  Quarterly  Allocation" 

0  4,  34  SAY  "for" 

0  5,  28  SAY  "Fiacal  Year" 

0  5,  41  SAY  QTPALLOC->FY 

0  9,  27  SAY  "Quarter* 

0  9,  39  SAY  QTRALLOC->QUARTER 

0  11,  27  SAY  "APC  Code* 

0  11,  39  SAY  QTRALLOC->APC 
0  13,  27  SAY  "Allocation" 

0  13,  39  SAY  QTRALLOC->ALLOCATION 
0  1,  14  TO  16,  59  DOUBLE 

0  7,  15  TO  7,  58 

0  18,  14  TO  20, 59 

0  19,  19  SAY  "Delete  thia  Record?  (Y/N)  "; 

GET  Maybe  PICTURE  " ! " 


EQUIPMENT  SCREEN  FILE 

Update  and  change  the  Equipment  information  in  the  Equipment  Databaae. 

(EMENU1_1  SCREEN  FILE] 

0  2,  17  SAY  "ENTEP  NEW  EQUIPMENT  DATA* 

0  4,  25  SAY  "EQUIFf'EUT  ■"TE  *’ 

0  4,  44  GET  EQUIP ->EOCODE 

0  6,  2  SAY  "SECT  DATE  ITEM  DESCFIPTI-^N  TYPE  URGENCY  QTY  UNIT  PRICE" 

0  7,  2  GET  EQUIP->SECTCODE 

07,  7  GET  EQUIP ->REQDATE 

0  7,  17  get  EQUIP->DESCRIPT 

0  7,  42  GET  EQUIP ->REQTYFE 

0  7,  52  GET  EQUlP->UP.GCODE 

0  7,  60  GET  EQUIP->QTY 

0  7,  67  SAY  *S* 

0  7,  69  GET  EQU1P->UNITPRICE 

0  9,  21  SAY  "STATUS  CODE  COMMENTS* 

0  10,  26  GET  E0U1P->STATUS 
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9 

10, 

41 

GET  EQUIP->COMMENTS 

9 

14, 

7 

SAY  "URGENCY  CODES 

TYPE  OF  PEOUEST  CODES 

STATUS  CODES" 

i» 

If, 

6 

SAY  "0 

deeded  Now 

imi-r 

tlEC*CASE 

FW 

Paperwork 

9 

17, 

6 

SAY  "1 

1  Year 

CEEF 

CEEF 

FJJ 

Pi-ID  " 

9 

18, 

6 

SAY  "2 

2  Years 

CAPR 

CAPR 

AP 

Approved 

9 

19, 

6 

SAY  "3 

3  Years 

OTHE 

OTHER 

OO 

On  Order" 

9 

20, 

6 

SAY  "4 

Not  Urgent 

RC 

Received" 

9 

13, 

4 

TO  21, 

22 

9 

13, 

28 

TO  21, 

52 

9 

15, 

29 

TO  15, 

51 

9 

15, 

5 

TO  15, 

21 

9 

1, 

0 

TO  11, 

79 

DOUBLE 

9 

3, 

1 

TO  3, 

78 

9 

13, 

58 

TO  21, 

75 

9 

15, 

59 

TO  15, 

74 

9 

5, 

24 

TO  5, 

51 

EQUIPMENT  UPDATE  FROM  RIR  SCREEN  FILE 


Special  update  screen  for  Equipment  when  the  Resource  Information  Report  Is  used. 
IEMENU2_2  SCREEN  FILE] 


9 

3, 

31 

SAY  "SECTION" 

9 

3, 

42 

SAY  EQUIP->SECTCODE 

9 

6, 

9 

SAY  "EQUIP  CODE  ITEM 

9 

7, 

10 

SAY  EQUIP ->EQCODE 

9 

7, 

21 

SAY  EQUIP->DESCRIPT 

9 

7, 

44 

GET  EQUIP “>QTY 

9 

7, 

50 

GET  EQUIP->UNITPRICE 

9 

7, 

64 

GET  EQUIP->STATUS 

9 

10, 

33 

SAY  "COMMENTS" 

9 

11, 

27 

GET  EQUIP->COMMENTS 

9 

14, 

12 

SAY  "Press  ESC  to  abort 

9 

2, 

5 

TO  13,  71  DOUBLE 

9 

4, 

6 

TO  4,  70 

DESCPTPTI'^M 


editing,  ENTER 


OTY  UNITPRICE  STATUS" 


to  complete  changes." 


MOEXP  SCREEN  FILE 


Update  and  change  the  monthly  expenditures  in  the  Budget  Database. 


9 

2, 

22 

SAY  "Enter  the  Monthly  Expenditure" 

9 

5, 

26 

SAY  "APC  Code" 

9 

5, 

38 

SAY  MOEXP->APC  FUNCTION  "!"  PICTURE 

9 

7, 

26 

SAY  "Month" 

9 

7, 

38 

SAY  MOEXP->MONTH 

9 

9, 

26 

SAY  "Expenses" 

9 

9, 

38 

GET  MOEXP->EXPENSES 

9 

4, 

15 

TO  10,  56  DOUBLE 

9 

21, 

15 

TO  24,  56 

OCCUPIED  SCREEN  FILE 

Special  output  screen  when  a  TDA  position  is  occupied  in  the  Personnel  Database. 
@  6,0  TO  11,79  DOUBLE 

9  7,5  SAY  "THAT  POSITION  IS  ALREADY  OCCUPIED  BY:  " 

9  8,5  SAY  "Last  Name:  ■+LNAME 
9  9,5  SAY  "First  Name:  "+FNAME 
9  10,5  SAY  "Rank:  "+RANK 
9  15,0 
HAIT 


PERRIR  B  SCREEN  FILE 


Special  input 


screen  for  personnel  information  when  the  Resource  Information  Report  is 


9 

9 

9 

9 

9 


1,  24  SAY  "UPDATE  FROM  R.I.F.  FEP'^PT" 

3,  0  SAY  "B.  CHANGES  TO  CURRENT  Tt A  (OTHER  THAN  LOSSES  OR  GAINS)" 
5,  22  SAY  "OLD  POSITION  NEW  POSITION" 

7,  2  SAY  "PARA  LINE  POSN  IDCODE  LAST  NAME  RANK 

9,  3  GET  OTDA  PARA  PICTURE  "99“" 


PAPA 


LINE 


Used . 


POSN" 
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@  9,  10  GET  0_TDA_LINE  PICTURE  "99" 

0  9,  17  get  0_TDA_P0SN  PICTURE  ’99" 

0  o,  2  3  GET  M  IF-CODE  PICTURE  "  !  0999* 

0  9,  31  GET  H_LNA11E  PICTURE  ’  !!!!!!!!!!!!!!!!  I  !!!  * 

0  9,  55  GET  M_RANK  PICTURE  ■!!!* 

0  9,  62  GET  M_TDA_PARA  PICTURE  "999’ 

0  9,  69  GET  M_TDA_LINE  PICTURE  •99’ 

0  9,  76  GET  M_TDA_POSN  PICTURE  ’99" 

0  13,  18  SAY  "PRESS  RETURN  (BLANK  ALL  ENTRIES)  TO  QUIT* 
0  7,  7  TO  9,  7 

0  7,  14  TO  9,  14 

0  7,  21  TO  9,  21 

0  7,  29  TO  9,  29 

0  7,  52  TO  9,  52 

0  7,  66  TO  9,  66 

0  7,  73  TO  9,  73 

0  5,  59  TO  9,  59  DOUBLE 

04,  0  TO  10,  79  DOUBLE 

0  6,  1  TO  6,  78 

0  8,  1  TO  8,  78 

0  0,  21  TO  2,  52 


PERSON  SCREEN  FILE 

Update  and  change  personnel  Information  in  the  Personnel  Database. 

0  0,  28  SAY  "UPDATE  PERSONNEL" 

0  2,  4  SAY  "ID  CODE  is" 

0  2,  15  SAY  PERSON->IDCODE 

0  4,  5  SAY  "Last  Name  First  Name  MI  RANK  BRANCH  MOS* 

0  5,  5  GET  PERSON->LNAME 

0  5,  28  GET  PERSON'>FNAME 

0  5,  48  GET  PERSON->RANK 

0  5,  56  GET  PERSON->BRANCH 

0  5,  65  GET  PERSON->MOS 

0  8,  5  SAY  "Arrival  Date . " 

0  8,  23  GET  PERSON->ARRDATE 

0  8,  38  SAY  "Anticipated  Date  of  Loss..." 

0  8,  65  GET  PERSON->ALOSS 

0  12,  18  SAY  "INDIVIDUAL  IS  ASSIGNED  TO  TDA  POSITION* 

0  14,  23  SAY  "TDA  Paragraph  Number  is" 

0  14,  47  SAY  PERSON->TDA_PARA 
0  15,  23  SAY  "TDA  Line  Number  is" 

0  15,  42  SAY  PERS0N->TDA_L1NE 
0  16,  23  SAY  "TDA  Position  Number  is" 

0  16,  46  SAY  PERSON->TDA_POSN 

0  18,  6  SAY  "NOTE:  If  Position  Number  is  99,  the  Individual  is  carried  as  excess" 

0  13,  16  TO  17,  57 

0  6,  4  TO  6,  74 

0  4,  53  TO  5,  53 

0  4,  62  TO  5,  62 

0  4,  4  5  TO  5,  4  5 

0  4,  26  TO  5,  26 

@3,  3  TO  10,  75  DOUBLE 


POSITION  SCREEN  FILE 

TDA  position  verification  output  screen  for  the  Personnel  Database. 

0  12,0  TO  17,79  DOUBLE 
0  13,5  SAY  "THE  POSITION  CHOSEN  WAS:  ’ 

0  14,5  SAY  "Job  Title:  ’+JOB  TITLE 
0  15,5  SAY  "Authorized  Bran-K: 

0  15,30  SAY  "Authorized  Grade:  "+AUXH  GP 
0  16,5  SAY  "Authorized  MOS:  "+AUTH  MOS 
0  16,30  SAY  "Authorized  Position:  " 

IF  AUTH  -  1 

?7  "YES" 

ELSE 

7?  "NO" 

END  IF 

0  22,0  WAIT 
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QTRALr.OC  SCREEN  FILE 

Update  and  change  quarterly  allocation  in  the  Budget  Database. 


e 

3,  19 

SAY 

"Enter  the  New  Quarterly  Allocation 

e 

4,  34 

SAY 

"for" 

e 

5,  28 

SAY 

"Fiscal  Year" 

e 

5,  41 

SAY 

QTRALLOC->FY 

e 

9,  27 

SAY 

"Quarter" 

e 

9,  39 

SAY 

QTRALLOC - >QDARTER 

e 

11,  27 

SAY 

"APC  Code" 

e 

11,  39 

SAY 

QTRALLOC->APC 

e 

13,  27 

SAY 

"Allocation" 

e 

13,  39 

GET 

QTRALLOC -  >ALLOCATI  ON 

1,  14 

TO  16,  59  DOUBLE 

e 

7,  15 

TO 

7,  58 

SOCIAL 

SCREEN  FILE 

Update  and  change  personal  information  in  the  Personnel  Database. 


1,  12 

SAY 

8 

1, 

57 

SAY 

e 

3,  28 

SAY 

m 

8 

4, 

0 

SAY 

m 

8 

5, 

3 

SAY 

m 

8 

6, 

3 

SAY 

m 

8 

8, 

0 

SAY 

m 

8 

9, 

3 

SAY 

m 

8 

11, 

2 

SAY 

m 

8 

11, 

13 

GET 

8 

11,  38 

SAY 

m 

8 

11,  50 

GET 

8 

13, 

2 

SAY 

m 

8 

13, 

25 

GET 

8 

13,  45 

SAY 

m 

8 

13,  47 

GET 

8 

13,  51 

GET 

8 

15,  18 

SAY 

m 

8 

15, 

35 

GET 

8 

17, 

2 

SAY 

m 

8 

17,  14 

GET 

8 

17, 

29 

SAY 

m 

8 

17,  52 

GET 

8 

19, 

10 

SAY 

m 

8 

19, 

27 

GET 

1 

8 

0, 

0 

TO 

2 

8 

10, 

0 

TO  20 

PRIVATE->IDCODE  PICTURE 


event  information.* 


PRIVATE->ADDRESS  FUNCTION  " ! * 


and  social” 


PRIVATE->TELEPHONE  FUNCTION  *'R”  PICTURE  *•(999)999-9999* 


PRIVATE->CITY 

PRIVATE->STATE 
PRIVATE->2IPCODE 
Date  of  Rank" 
PRIVATE->DOR 
Wife's  Name" 
PR1VATE->WIFE 


PP.IVATE->CHILDREN  FUNCTION  "S24* 


FUNCTION  "P"  PICTUPE  "99999-9999" 


PRIVATE->COMMENTS 
,  77 


SURVEY  SCREEN  FILE 

Input  screen  for  the  Patient  Satisfaction  Survey  in  the  Satisfaction  Database. 


8 

1, 

7 

SAY  "MONTH" 

8 

1, 

13 

GET  SURVEY->MONTH  RANGE  1,  12 

8 

1, 

18 

SAY  "YEAR" 

8 

1, 

23 

GET  SDRVEY->YEAR 

8 

1, 

29 

SAY  "CLINIC" 

8 

1, 

36 

GET  SUPVEY->SECTCODE 

8 

1, 

43 

SAY  "DOCTOR" 

8 

1, 

51 

GET  SURVEY ->DOCTORNAME 

8 

3, 

18 

SAY  "l.A.  Days  to  get  appointment. 

l.A 

8 

3, 

58 

GET  SURVEY->APPTDAYS  RANGE  1,  6 

8 

4, 

20 

SAY  "B.  Acceptability. 

B." 

8 

4, 

58 

GET  SURVEY->ACCAPPT  RANGE  1,  2 

8 

6, 

18 

SAY  "2.  Records  ready  on  time. 

2." 

8 

6, 

58 

GET  SURVEY->RECORDS  RANGE  1,  2 

8 

8, 

18 

SAY  "3. A.  Waiting  time. 

3.  A 

8 

8, 

58 

GET  SURVEY->WAITTIME  RANGE  1,  4 

8 

9, 

2S> 

SAY  "B.  Acceptability. 

B." 

8 

9, 

58 

GET  SORVEY->ACCWAIT  RANGE  1,  2 
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@ 

11. 

18 

SAY  * 

@ 

11, 

58 

GET 

@ 

1C, 

18 

SAY  * 

0 

12,  58 

GET 

0 

13,  18 

SAY  * 

0 

13,  58 

GET 

0 

14,  18 

SAY  * 

0 

14,  58 

GET 

0 

15,  18 

SAY  *1 

0 

15, 

58 

GET 

0 

16, 

18 

SAY  * 

0 

16,  58 

GET 

0 

17,  17 

SAY  * 

0 

17,  58 

GET 

0 

20,  20 

SAY  ", 

0 

20,  58 

GET 

0 

21,  19 

SAY  * 

0 

21, 

55 

GET 

0 

0, 

4 

TO  22 

0 

2,  15 

TO  10 

0 

10,  15 

TO  18 

4.  Courtesy,  receptionists. 
SURVEY->RECEPT  RANGE  1,  5 

5.  Courtesy,  nurses. 
SOP.VEY->MURSE  RANGE  1,  5 

6.  Courtesy,  doctors. 
SURVEY->DOCTORS  RANGE  1,  5 

7.  Explanation  of  procedures. 
SURVEY ->EXP  LAIN  RANGE  1,  5 

8.  Time  spent  with  doctor. 
SURVEY->TIMESPENT  RANGE  1,  5 

9.  Cleanliness. 

SURVEY->CLEAN  RANGE  1,  S 

10.  General  satisfaction. 
SURVEY->SATIS  RANGE  1,  5 

ARE  THERE  COMMENTS  TO  ADD?  (Y/N) 

SURVEY->PATCOMMENT 

(Cntrl  PgDn  to  Enter  Comments)* 

SURVEY  -  >COMMENTS 

,  73  DOUBLE 

,  60 

,  60 


4. * 

5.  * 

6. - 

7. * 

8. * 

9. * 

10. " 


TDA  SCREEN  FILE 

Update  and  change  the  TDA  information  in  the  Personnel  Database. 


0 

2, 

15 

SAY 

"TDA  Listing" 

0 

4. 

10 

SAY 

"Paragraph  Number" 

0 

4, 

27 

SAY 

TDA->TDA  PARA 

0 

4, 

54 

SAY 

•POSITION  TITLE" 

0 

6, 

10 

SAY 

"Line  Number" 

0 

6, 

28 

SAY 

TDA->TDA  LINE 

0 

6, 

47 

SAY 

"Job  Title" 

0 

6, 

59 

GET 

TDA->JOB_TITLE 

0 

8, 

10 

SAY 

"Position  Number* 

0 

8, 

28 

SAY 

TDA->TDA  POSN 

0 

12, 

26 

SAY 

■POSITION  CHARACTERISTICS 

0 

14, 

24 

SAY 

•APC  Code* 

0 

14, 

46 

GET 

TDA->APC 

0 

15, 

24 

SAY 

"Authorized  Branch" 

0 

15, 

46 

GET 

tda->aoth_br 

0 

16, 

24 

SAY 

"Authorized  Grade" 

0 

16, 

46 

GET 

TDA->AUTH  GR 

0 

17, 

24 

SAY 

"Authorized  MOS* 

0 

17, 

46 

GET 

TDA->AUTH_MOS 

0 

18, 

24 

SAY 

"Position  Authorized" 

0 

18, 

46 

GET 

TDA->AUTH 

0 

19, 

29 

SAY 

"1-YES  O-NO" 

0 

3, 

7 

TO 

9,  34 

0 

6, 

35 

TO 

6,  44 

0 

5, 

45 

TO 

7,  79 

0 

13, 

21 

TO  20,  55 

TDAINPUT  SCREEN  FILE 

Input  screen  for  entering  a  requested  TDA  position  in  the  PErsonnel  Database. 
0  6,0  TO  11,79  DOUBLE 

@7,5  SAY  "WHAT  POSITION  WILL  THIS  PERSON  OCCUPY  ; 

OR  ENTER  A  ZERO  (0)  TO  QUIT:  “ 

@8,5  SAY  *TDA  Paragraph  Number:*  ; 

GET  M_TDAPARA  PICTURE  “999* 

READ 

*-  SEE  IF  THEY  WANT  TO  QUIT 
IF  M_TDAPARA  -  0 
TRY- . F . 

LOOP 

ENDIF 

@9,5  SAY  "TDA  Line  Number:*  ; 

GET  M_TDALINE  PICTURE  *99’ 

@  10,5  SAY  "TDA  Position  Number:"  ; 

GET  M  TDAPOSN  PICTURE  "99" 
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UPCMF.REQ  SCREEN  FILE 

Special  update  screen  for  CME  requests  when  only  actual  costs  are  entered  In  Personnel  Database. 

e  1,  2  SAY  "SUBJECT:  APPLICATION  FOR  CONFERENCE/MISSION  TRAVEL  IN  FISCAL  YEAR" 

e  1,  68  SAY  M_FY  PICTURE  "99" 

0  3,  0  SAY  "1.  Type  of  Travel  Requested . " 

0  3,  34  SAY  CMEREQ->TYPE  PICTURE  " ! " 

0  4,  3  SAY  "C-Conference/Meeting  Travel  G-Goneral  Mission  Travel  B-Board  Certif icatlo" 

0  6,  0  SAY  "2.  ID  CODE  of  person  requesting  the  travel  is" 

0  6,  46  SAY  M_IDCODE  PICTURE  •!9999" 

0  6,  52  SAY 

0  8,  0  SAY  "4.  Purpose  of  Travel  Is" 

0  8,  24  SAY  CMEREQ->PORPOSE 

0  8,  45  SAY  ".  5.  Registration  Fee  $" 

0  8,  71  GET  CMEBEQ->REGFEE 

0  10,  0  SAY  "6.  Destination" 

0  10,  16  SAY  CMEREQ->LOCATION 
0  10,  42  SAY  "Mode  of  Travel  is" 

0  10,  60  SAY  CMEREQ->TVLMODE 

0  11,  42  SAY  "F-FLY,  G-GOVT  VEH,  P-POV,  O-OTHER" 

0  13,  0  SAY  "8.  Leave  Dates  Starting  Date" 

0  13,  31  SAY  CMEREQ->START 
0  13,  41  SAY  "Ending  Date" 

0  13,  53  SAY  CMEREQ->END 
0  14,  3  SAY  "Duration" 

0  14,  14  SAY  CMEREQ->DURATION 
0  14,  19  SAY  "days" 

0  16,  0  SAY  "13.  TRAVEL  COST  S" 

0  16,  18  GET  CMEREQ->TRAVELCOST 
0  16,  29  SAY  "PER  DIEM  COST  $" 

0  16,  44  GET  CMER£Q->PERDIEM 
0  16,  56  SAY  "REIMBURSABLES  $• 

0  16,  71  GET  CMEREQ->REIMB 
0  18,  17  SAY  "TOTAL  COST  OF  TRAVEL  $" 

0  18,  40  SAY  CMEREQ->TOTALCOST 
0  20,  12  SAY  "EXPENSES  REFLECT  THE  * 

IF  C_C0DE  -  "A" 

0  20,  33  SAY  "ACTUAL  COST  OF  TRAVEL" 

ELSE 

0  20, 33  SAY  "ESTIMATED  COST  OF  TRAVEL" 

ENDIF 

00,  0  TO  2,  79 

0  19,  10  TO  21,  58 
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APPENDIX  C.  BUDGET  PRO(3<AMS 


»BU  or  titoauiME 


MfWU.PBG 
tHDfUl.PBG 
Manus.  PRO 
MOMUS .  PRO 
MailU4.PR0 
Maif04_l.PR0 
MailU4  2. PRO 
BMfM0423  •  PRO 
MaMU4  4. PRO 


DZSeiAZlOR 

The  purpose  of  this  programming  code  is  to 
facilitate  the  understanding  of  the 
requirements  presented  in  Chapter  5  of  this 
thesis.  The  nature  of  this  project  precludes 
it  actual  i/rpia/nentation  in  DBASE  III*,  To 
fully  implement  the  requirements  the  system 
designer  will  need  a  full  range  of  capabilities 
that  does  not  currently  exist  in  DBASE  III*. 

DBASE  III*  served  as  the  modeling  tool  by 
which  the  screens  were  generated  and  where 
necessary,  specific  code  was  written  to 
illustrate  a  point.  The  actual  working  code 
merely  acts  as  a  shell  in  which  to  run  the 
menus.  A  close  analysis  of  the  program  code  can 
facilitate  inplementation  in  a  more  suitable 
language,  i,e,,  PARADOX,  which  can  support  the 
graphics  and  high  level  relationships  involved 
in  the  various  databases .  Where  the  actual 
requirements  process  may  appear  to  Jba  unciear, 
conwnents  were  added  within  the  code  to  explain 
these  areas  to  the  designer. 

*  Program. . t 

*  Author...!  ELBERT  T.  SEAN  i  JOAN  ZZ»t4ERMAN 

*  Data . !  02/14/89 

*  Motica...!  Copyright  (c>  1989,  ELBERT  T.  SHAN  i  JOAN 
ElMaRKAN,  All  Righta  RasarvaO 

*  Notaa....:  Tha  Main  angina  aanu  for  tha  Budgat  Syatam 
BET  TALK  OTT 

SET  BELL  orr 
SET  ESCAPE  orr 
SET  CONPIRM  ON 

DO  NSZLE  .T. 

*  — >->Diapiay  nanu  optlona,  cantarad  on  tha  acraan. 

*  drat#  manu  bordar  and  print  haading 
CLEAR 

*  2,  0  TO  14,79  DOUBLE 

*  3,  18  SAY  (DEPARTMENT  Or  PAMTLY  PRACTICE  BUDGET  SYSTEM) 
i  4,1  TO  4,78  DOUBLE 

*  '•display  datail  llnaa 

9  7,29  SAY  (1.  UPDATE  TTSCAL  YEAR  ALLOCATIONS) 

9  8,29  SAY  [2.  UPDATE  MONTHLY  EXFENLXTUKES] 

9  9,29  SAY  (3.  UPDATE  APC  INTORMATIOK  rXLEJ 

9  10,29  SAY  (4.  PRINT  REPORTS) 

9  12,  29  SAY  '0.  EXIT' 

STORE  0  TO  aalaetnun 
9  14,33  SAY  '  aalact 

9  14,42  GET  aalaetnun  PICTURE  "9"  RANGE  0,4 

READ 

DO  CASE 

CASE  aalaetnun  ■  0 
CLEAR  ALL 
RETURN 

CASK  aalaetnun  >  1 


*  DO  UPDATE  PY  ALLOCATIONS 
DO  BNENUl 

SET  coMrzRM  orp 

RAZT 

SET  CONTIRM  ON 

CASE  aalaetnun  •  2 

*  DO  UPDATE  EXPENDITURES 
DO  MaHU2 

SET  coMriRM  orr 
BAIT 

SET  CONPIRM  ON 

CASE  aalaetnun  ■  3 

•  DO  APC  INPORMATION  PILE 

DO  BMENU3 

SET  courzRM  orr 

MAIT 

SET  CONPIRM  ON 

CASK  aalaetnun  *  4 

•  DO  PRINT  REPORTS 

DO  aMSNU4 

SET  CONFIRM  OPP 
RAIT 

SET  CONPIRM  ON 

ENDCASB 

ENDDO  T 
RETURN 

*  EOF!  BMENU.PRO 


*  Pregran. . t 

MHUl.PRO 

*  Author...:  ELBERT  T.  SEAN  4  JOAN  ttlMIRMAN 

*  Data . t  02/14/89 

*  Notiea...:  Copyright  (e)  1989,  ELBERT  T.  SEAN  4  JOAN 
EIIMRRMAN,  All  Rights  Rasarvad  * 

Notaa....:  Updataa  tha  Quartarly  Alloeatlon  Pila 

SET  TALK  orr 

SET  BELL  orr 

SET  ESCAPE  orr 

USE  QTRALLOC 

M_rY  •  0 

*  Claar  Scraan  for  EY  input  an  allot#  for  tha  uaar  to  aalact 
tha  riaoal  Yaar 

*  Typieally,  tha  uaar  t#lll  only  ba  oparatlng  in  ona  EY 
CLEAR 

96,0  to  8,79  DOUBLE 

97,18  SAY  "Entar  tha  Eiaeal  Yaar  for  tha  Allocations:”  ; 

GET  M_rY  PICTURE  "99" 

READ 

DO  NBILK  .T. 

•  -w>Dlsplay  nanu  options,  cantarad  on  tha  scraan. 

•  drat#  Mnu  bordar  and  print  haading 
CLEAR 

9  2,  0  TO  14,79  DOUBLE 

9  3,6  SAY  [UPDATE  FISCAL  YEAR  ALLOCA 
T  I  o  N  S) 

•  4,1  TO  4.78  DOUBLE 

9  7,25  SAY  [1.  ADD  ALLOTATIONS  POP  EY  )+STR(M  FY,2) 

9  8,25  SAY  [2.  CHANOE  ALLOCATIONS  POP  FY  J fSTP (M^PY, 2) 

9  9,28  SAY  [3.  REMOVE  ALLOCATIONS  PROM  PY  )tSTR(H  PY.Z) 

9  10,2$  SAY  [4.  REVIKN  ALLOCATIONS  FOR  PY  )4$TR(M  PY,2) 

9  12,  29  SAY  '0.  EXIT' 

STORE  0  TO  aalaetnun 
9  14,33  SAY  ”  aalact 

9  14,42  GET  aalaetnun  PICTURE  "9”  RANGE  0,4 
READ 

DO  CASE 

CASE  aalaetnun  •  0 
SET  BELL  ON 
SET  TALK  ON 
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CLOSE  ALL 
CLEAA  ALL 
ASTOMt 


CASE  ■•X«otnua  ■  1 
•  DO  ADD  ZMrOAMAriOH 


Adding  •  .T. 

DO  miLB  Adding 
CLEAA 

M  APC  •  SPACE  (4) 


•nt«r  lt» 
•IfPP" 


<l«t  th«  Section  th«  XJwx  want*  to  work  with 
I  6,0  TO  10,79  DOODLE 

f  7,10  SAY  *Bat«r  th«  APC  Ntmbwr  of  Swetien  to 

allocation"  GET  M_APC  PICTURE 

9  9,10  SAY  "or  Praaa  Ratuzn  to  ^ZT" 

READ 


*-Nothing  antarad,  ao  QUIT 
If  M^APC  -  •  " 

Adding  •  . r . 

LOOP 

EMDir 


*-Haka  aura  tha  APC  axiata  in  tha  Actlva  Pila 
USE  APC  IDDEX  APC 
SEARCH-  UPPER (M_APC) 

LOCATE  FOR  APC-SEARCfl 
xr  rouMDO 
CLEAR 

•  6,0  TO  9,79  DOUBLE 

i  7,S  SAY  "Saction:  "♦SECTION 

•  7,35  SAY  "Saetion  Coda:  "♦S_CO0E 
9  8,5  SAY  "Point  of  Contact s "♦POC 
9  8,35  SAY  ; 


"Talapbona : 


rila,; 


"♦TRAM8rORH(Talapbona, " <999) 999>9999") 

ELSE 

*-4farn  Uaar  that  APC  antarad  doaa  not  axlxt 
CLEAR 

9  6,0  TO  8,79  DOUBLE 

9  7,5  SAY  "APC  raquaatad  la  not  in  tha  Maatar 
Plaaaa  Try  again." 

?7  CIR(7) 

9  15,0 

BAIT  "Praaa  Raturn  to  try  again..." 

LOOP 

ENDXr 


*-rind  out  wlab  quartar'a  allocation  tha  uaar  want* 

to  add 

M  OTR  -  0 
9’l4,0  TO  16,45 

9  15,5  SAY  "Entar  tha  Quartar  You  ffish  to  Add: 

GET  M  QTR  PICTURE  "9" 

READ 

USE  QTRALLOC  INDEX  QTRALLOC 


*-riltar  out  all  axtranaous  information  and 
raatriet  to  uaar  input* 

SET  FILTER  TO  FY^^FY  .AND.  OUARTER-M_QTR 
GO  TOP 

*-Chaek  and  aaa  if  tha  uaar  haa  alraady  antard  a 
allocation  for  this 

*>APC  and  Q\iartar 
LOCATE  FOR  APC-M_APC 
IF  FOUND!) 

CLEAR 

NAIT  "RECORD  ALREADY  EXISTS,  Praaa  Raturn  to 

Changa  it  " 

*-If  found,  juat  Edit  tha  axiating  racord 
SET  FORHAT  TO  QTRALLOC 

READ 

CLOSE  FORMAT 

ELSE 

*'Craata  a  naw  racord 
SET  rOPMAT  TO  QTRALLOC 

CLEAR 

BAIT  "ADDING  NEB  RECORD,  Praaa  Raturn  to 

Continua" 

APPEND  BLANK 

*-Bhat  tha  uaar  has  input,  don't  naka  than 

ralnput  it 

REPLACE  FY  BITS  M  FY 
REPLACE  APC  BITB  M_APC 
REPLACE  QUARTER  BITH  M_QTR 
READ 

CLOSE  FORMAT 
EHDIF 


9  5,0  SAY  "Plaaaa  stand  by  whlla  1  raindax  tha 

flla. 

SET  TALK  ON 

REINDEX 

SET  TALK  OFF 

CLOSE  ALL 

SET  CONFIRM  OFF 

BAIT 

SET  CONFIRM  ON 


CASE  salaetntn  ■  2 
•  DO  CHANGE  INFORMATION 


Adding  -  .T. 

DO  BSZLE  Adding 
CLEAR 

M_APC  -  SPACE  <4) 

9  6,0  TO  10,79  DOUBLE 

9  7,10  SAY  "Entar  tha  Ape  Mumbar  of  Saetion  to 


updata  it* 


allocation"  GET  M  APC  PICTURE  ”1999" 


9  8,10  SAY  "or  Praaa  Raturn  to  QUIT" 
READ 


IF  MJiPC  -  " 
Adding  - 
LOOP 

ENDIF 


F. 


USE  APC  INDEX  APC 
SEARCH-  UPPER <H_APC) 

"-Locata  tha  APC  and  varify  it*  axiatanca 
LOCATE  FOR  APC-8EARCH 
IF  FOUND!) 

CLEAR 

9  6,0  TO  9,79  DOUBLE 
9  7,5  SAY  "Saetion:  "4SBCT10N 
9  7,35  SAY  "Saetion  Coda:  "48  CODE 
9  8,5  SAY  "Point  of  Contact :”Tpoc 
9  8,35  SAY  ; 


"Talapbona: 


Fila,; 


"4TRANSF0RM  (Talapbona, " <999)  999-9999*) 

ELSE 

CLEAR 

9  6,0  TO  8,79  DOUBLE 

9  7,5  SAY  "Af-C  raquaatad  is  not  in  tha  Hastar 
Plaaaa  Try  again.” 

77  CBR<7) 

9  15,0 

BAIT  "Praaa  Raturn  to  try  again...” 

LOOP 

ENDIF 


M_QTR  •  0 
9  14,0  TO  16,45 

9  15,5  SAY  "Entar  tha  Quartar  You  Blab  to  Changa: 
GET  M_QTR  PICTURE  "9" 

READ 

USE  QTRALLOC  INDEX  QTRALLOC 
"-Filtar  out  all  axtranaoua  information  and 
raatriet  to  uaar  inputs 

SET  FILTER  TO  FY-M^FY  .AND.  0UARTER-M_QTR 
GO  TOP 

LOCATE  FOR  APC-M^APC 
IF  FOUND!) 

CLEAR 

BAIT  "RECORD  ALREADY  EXISTS,  Praaa  Raturn  to 
Changa  it"  SET  FORMAT  TO  QTRALLOC 

READ 

CLOSE  FORMAT 
ELSE 

SET  FORMAT  TO  QTRALLOC 
CLEAR 

BAIT  "ADDING  NEB  RECORD,  Frasa  Raturn  to 

Continua” 

APPEND  BLANK 
REPLACE  FY  BITB  M  FY 
REPLACE  APC  BXTR  Pi  APC 
REPLACE  QUARTER  BITS  M_QTR 
READ 

CLOSE  FORHAT 
ENDIF 


ENDDO 

SET  FILTER  TO 
CLOSE  ALL 
SET  CONFIRM  OFF 
BAIT 

SET  CONFIRM  ON 


ENDDO 

SET  FILTER  TO 


CASE  aalactnun  -  3 
•  DO  REMOVE  INFORMATION 
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Mor*  •  .T. 

DO  MIXLl  Mor« 

CLkAt' 

M_AtC  -  8rACt(4) 

I  6,0  TO  10,79  DOUBLE 

9  7,10  SAY  "Bnt^r  tb«  APC  M\imb«r  of  th«  Soetlon 
to  doloto  ita 

allocation”  GET  N_APC  PICTURE  ”1999" 

9  0,10  SAY  "or  Praaa  Roturn  to  QUIT" 

READ 


ir  M  APC  • 
Mora  -  . 
LOOP 
IMDXr 


USE  APC  INDEX  APC 
SEARCH*  UPPER <M_APC) 

LOCATE  rOR  APC*SEARCB 
IP  POUND O 
CLEAR 

9  6,0  TO  9,79  DOUBLE 
9  7,5  SAY  "Section:  "-fSECTIOM 
9  7,35  SAY  "Section  Code:  "4-S  CODE 
9  0,5  SAY  "Point  of  Contact : "TpOC 
9  0,35  SAY  ; 


"Telephonat  "-fTRANSPORM (Telephone,  "  (999)  999-9999") 

ELSE 

CLEAR 

9  6,0  TO  0,79  DOUBLE 

9  7,5  SAY  "APC  requeated  la  not  In  the  Hester 

Pile, 


Please  Try  aqeln.” 

??  CBR(7) 

9  15,0 

NAXT  "Press  Return  to  try  aqaln..." 
LOOP 
ENDZP 


M_QTR  •  0 
9”l4,0  TO  16,45 

9  15,5  SAY  "Enter  the  Quarter  You  Nish  to  Delete: 
GET  M  QTR  PICTURE  "9" 

READ 

USX  QTRALLOC  INDEX  QTRALLOC 

SET  PXLTSR  TO  PY«H  PY  .AND.  QUARTER«M  QTR 

00  TOP  ” 

LOCATE  POR  APC*H  APC 
IP  POUND () 

CLEAR 

Maybe  ■  ”  ” 

SET  PORMAT  TO  OELQALLO 
READ 

CLOSE  PORMAT 
IP  UPPER (Maybe)  •  "Y" 

DELETE 

ENDIP 

ELSE 

9  20,0  CLEAR 

7  "Can't  find  the  requeated  record" 

7?  CHR(7) 

BAIT  "Press  any  key  to  try  eqeln..." 

LOOP 

ENDIP 

ENDDO 


*-01ve  the  user  a  chance  to  change  their  mind  about 
deleting  data 

YorN  ■  "  " 

CLEAR 

9  5,1  SAY  "Pemanently  renove  records  marked  for 
deletion  noe?  (Y/N) "  get  YorN  PICTURE 

"! " 

9  7,1  SAY  "(Process  may  take  a  few  minutes  to 
eoaiplete . . )  " 

READ 

IP  YorN  «  "Y" 

SET  FILTER  TO 

9  5,0  SAY  "Please  stand  by  while  I  relndex  the 

file. . " 

SET  TALK  ON 
REINDXX 
SET  TALK  OPP 
ELSE 

SET  FILTER  TO 
Nodels  -  0 

"--Count  the  number  of  records  to  be  deleted 
7  "Counting...  Please  wait." 

COUNT  POR  DELETED o  TO  Nodels 

Permiss  •  "N" 

DO  NBILE  Permiss  -  "N"  .AND.  Nodels  >  0 
CLEAR 


Dtt.ETBPO 


Number):  "; 


"Display  all  deleted  records 
7 

DISPLAY  APC,  PY,  QUARTER,  ALLOCATION  POR 
7 

Permiss  •  "  ” 

"-Give  user  ell  or  seme  choice 
9  23,5  SAY  "OR  to  delete  all  these7  (Y/N)  *; 
SET  Permiss  PICTURE  "I” 

READ 

"—IP  not  OR  to  delete  all,  find  out  which 
IP  Permiss  f  "Y" 

RecNo  ■  0 
9  20,0  CLEAR 

"-Find  Out  which  Records  to  recall 
9  23,5  SAY  "Recall  which  one  (Record 

GET  RecMo  PICTURE  ”999999” 


IP  ReeNo  >  0  .AND.  RecNo  <-  RECCOUNTO 
GOTO  ReeNo 
IP  DELETED  0 
RECALL 

Models  ■  Models  -  1 
ENDIP 
ELSE 

9  20,0  CLEAR 

9  23,5  SAY  "Mo  such  record: 

"4STR (RecHO,  4) 

>  CtR(7) 

BAIT 

ENDIP 

ENDIP 

ENDDO  (Petmlsa  and  No-dels) 

SET  TALR  OH 
CLEAR 

9  2,0  SAY  '  ' 

7  'PACRIHQ  DATABASE  TO  REMOVE  RECORDS  MARKED  POR 
DELETION' 

PACK 


ENDIP 

SET  TALR  OPP 
SET  CMn'IRM  OPP 
BAIT 

SET  CONFIRM  ON 

CASE  selectnum  >  4 
•  DO  REVIEB  INFORMATION 
CLEAR 

H  QTR  ■  0 

9“6,0  TO  0,79  DOUBLE 

9  7,15  SAY  "Enter  the  Quarter  to  Review"; 

GET  M  QTR  PICTURE  "9"  RANGE  1,4 
READ 

SET  FILTER  TO  0UARTER-M|_0TR  .AND.  PY-M^^PY 
"Display  only  those  records  user  desires 
GO  TOP 

BR0B8E  NOAPPEND  NOMENU 
SET  FILTER  TO 
SET  CONFIRM  OPP 
BAIT 

SET  CONFIRM  ON 

ETIDCASE 

ENDDO  T 
RETURN 

•  EOF:  BMENUl.PRG 


"  Program. . : 

wmm  .PRO 

•  Author...:  ELBERT  T.  SRAB  C  JOAN  EIMKERMAN 

•  Date . :  02  14,59 

"  Notice...:  Copyright  (e)  1989,  ELBERT  T.  SRAB  «  JOAN 
EIMaRMAN,  All  Rights  Reserved 

•  Notes . . . . : 

SET  TALR  OPP 
SET  BELL  OPP 
SET  ESCAPE  OPP 
SET  CONFIRM  ON 
USE  MOEXP 
CLEAR 

M  PY  ■  0 

9?, 0  to  8, 79  DOUBLE 

97,15  SAY  "Enter  the  Fiscal  Year  for  the  Allocations:"  ; 
GET  M_PY  PICTURE  "99" 

READ 
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DO  WIXLI  .T. 

•  <— <-Dlrpl«y  iMnti  options,  csntarod  on  ths  serssn. 

•  disw  tliwliu  b<-'l  l«i  OIrJ  pill.'.  li«rtJll<J 

CLgAR 

•  2,  0  TO  14,79  DOODLI 

•  2,8  tJ^Y  (UPDATE  MONTHLY  EXPtMDITO 
RES]  t  4,1  TO  4,78  DOUBLE 

•  Ostall  linos 

f  7,25  BAY  (1.  ADD  EXPENDITURES  FOR  PY  ]tSTR<M  PY,!) 

I  8,25  SAY  [2.  CHANGE  EXPENDITURES  FOR  FY  148TR(M  FY,2> 
t  9,25  SAY  (9.  REMOVE  EXPENDITURES  FROM  TY  ) tSTR (M_FY, 2> 


CASE  M  MONTH  >  6 

REPUICE  QUARTER  WITH  4 


CASE  H  MONTH  >  3 

RBI  LACE  QUARTER 


WITH  3 


CASE  M_MONTB  >«  1 

REPLACE  QUARTER  NZTH  2 

ENDCASE 

READ 

CLOSE  FORMAT 
ENDIF 


8  10,25  SAY  (4.  REVIEN  EXPENDITURES  FOR  FY  ] 49TR <M_rY, 2) 
i  12,  30  SAY  '0.  EXIT' 

STORE  0  TO  s«l«etniai 
f  14,33  SAY  ”  s«l«et 

•  14,42  GET  soloetnuM  PICTURE  "9”  RANGE  0.4 
READ 

DO  CASS 

CASS  snlsctniai  •  0 
CLEAR  ALL 
CLOSE  ALL 
RETURN 


ENDDO 

SET  FILTER  TO 

I  5,0  SAY  "Plsns*  stand  by  whlla  I  ralndax  tba 

flla. . • 

SET  TALK  OH 

RSINDEX 

SET  TALK  OFF 

CLOSE  ALL 

SET  CONFIRM  OFF 

NAIT 

SET  CONFIRM  OH 


CASS  salaetnuM  «  1 
*  DO  ADD  INFORMATIOH 
Adding  •  .T. 

DO  NHILE  Adding 
CLEAR 

M  APC  -  SPACE (4) 
f”6,0  TO  10,79  DOUBLE 

t  7,10  SAY  "Entas  tha  APC  of  tha  Saetion  to 

updata 

axpandituras”  GET  M  APC  PICTURE 
■1999"  *“ 


i  8,10  SAY  "or  Prass  Raturn  to  QUIT* 
READ 

IF  M^APC  •  -  - 

Adding  •  ,r. 

LOOP 

ENDIF 

USE  APC  INDEX  APC 
SEARCH*  UPPER  (M  APC) 

LOCATS  FOR  APC-?£ARCfl 
IF  FOUND  0 
CLEAR 

•  6,0  TO  9,79  DOUBLE 
8  7,5  SAY  "Saetion:  "-fSECTlON 
8  7,35  SAY  "Saetion  Coda:  "tS  CODE 
8  «»8  SAY  "Point  of  Contact: "+POC 
8  8,35  SAY; 


"Talapbona:"4TRAN8F0RM(Talaphona.  " (999)  999*9999") 

ELSE 

CLEAR 

8  6, 0  TO  8, 79  DOUBLE 

8  7,5  SAY  "APC  raquaatad  la  not  in  tba  Maatar 

Fila,  Plaaaa 


Try  again." 

77  C8R(7) 

8  15.  0 

NAIT  "Praaa  Raturn  to  try  again..." 
LOOP 
ENDIF 


M_M0NTH  •  0 
8  14,0  TO  16,45 

8  15,5  SAY  "Entar  tba  Month  You  Nlah  to  Add:  "; 
GST  M^MONTH  PICTURE  "99"  RANGE  1,12 

READ 

USE  MOSXP  INDEX  MOCXP 

SET  FILTER  TO  FY-M_FY  .AND.  MONTH*M_NONTH 
GO  TOP 

LOCATS  FOR  APC«M_APC 
IF  FOUND  0 
CLEAR 

NAIT  "RECORD  ALREADY  EXISTS.  Praaa  Raturn  to 
Changa  it  "  SET  FORMAT  TO  MOEXP 

READ 

CLOSE  FORMAT 

ELSE 

SET  FORMAT  TO  MOEXP 
CLEAR 

NAIT  "ADDING  NSN  RECORD,  Praaa  Raturn  to 

Contlnua" 

APPEND  BLANK 

REPLACE  FY  NITH  M_FY 

REPLACE  APC  NITH  H_APC 

REPLACE  MONTH  NITH  H_MONTB 

* — Raplaea  Quartat  baaad  on  Month  antarad 

DO  CASE 

CASS  M  MONTH  >  9 

REPLACE  QUARTER  NITH  1 


CASE  aalactnun  ■  2 
■  DO  CHANGE  INFORKATION 
Adding  •  .T. 

DO  NBlLE  Adding 
CLEAR 

M_APC  •  SPACE (4) 

8  6.0  TO  10,79  DOUBLE 

8  7,10  SAY  "Entar  tha  APC  Nunbar  of  tba  Saetion 
to  updata  ita  axpandlturaa"  GET  M_APC  PICTURE  "1999" 

8  8,10  SAY  "or  Praaa  Raturn  to  QUIT" 

READ 


IP  M^APC  -  " 
Adding  * 
LOOP 
ENDIF 


.F. 


USE  APC  INDEX  APC 
SEARCH-  UPPER (H_APC) 

LOCATE  FOR  APC-SEARCH 
IF  FOUND () 

CLEAR 

8  6,0  TO  9,79  DOUBLE 
8  7,6  SAY  "Saetion:  "♦SECTION 
8  7,35  SAY  "Saetion  Coda:  ”♦$  CODE 
8  8,5  SAY  "Point  of  Contact :  "TpOC 
8  8,35  SAY  ; 


"Talaphona:"4TRANSF0RM(Talaphona, " (999) 999*9999") 

ELSE 

CLEAR 

8  6,0  TO  6,79  DOUBLE 

8  7,5  SAY  "APC  raquaatad  la  not  in  tha  Maatar 

Flla,;  Plaaaa 


Try  again." 


7?  CHR(7) 

8  15,0 

NAIT  "Praaa  Raturn  to  try  again..." 
LOOP 


M  MONTH  •  0 
8”l4,0  TO  16,45 

8  15,5  SAY  "Entar  tha  Month  You  Nish  to  Changa: 

GET  M_MONTB  PICTURE  "99"  RANGE  1,12 

READ 

USB  MOEXP  IIOEX  MOEXP 

SET  FILTER  TO  FY-M_FY  .AND.  I40NTB-H_M0NTH 
GO  TOP 

LOCATE  FOR  APC-M_APC 
IF  FOUND  0 
CLEAR 

NAIT  "RECORD  ALREADY  EXISTS,  Praaa  Raturn  to 
Changa  It"  SET  FORMAT  TO  MOEXP 

READ 

CLOSE  roPMRT 
ELSE 

SET  FORMAT  TO  MOEXP 
CLEAR 

NAIT  "ADDINS  NSN  RECORD,  Praaa  Raturn  to 

Contlnua" 

APPEND  BLANK 
REPLACE  FY  NITH  M  FY 
REPLACE  APC  NZTH  M_APC 
REPLACE  MONTH  NITH  H_MO(ITH 

* — Automatically  Raplaea  Quartat  baaad  on  Month 

antarad 

DO  CASE 

CASE  M_MONTB  >  9 

REPLACE  QUARTER  NITH  1 
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CASE  >  6 

AKPLACE  QQAPTEA  NITR  4 

CASE  M  MONTH  >  3 

HEPLACE  QOAATBR  NITB  3 

CASE  M^MONTB  >•  1 

HEPXACE  QUARTER  WITH  3 

EMDCASE 

READ 

CLOSE  rORMAT 

BMDir 

EMDDO 

SET  riLTIR  TO 

i  5,0  SAY  "PlMs*  atand  by  whlla  I  ralndax  tha 

fUa.  .• 

SET  TALK  OR 
REXHDEX 
SET  TALK  orr 

CLOSE  ALL 

SET  coiiriRH  orr 

1IA2T 

SET  CONFIRM  ON 

CASE  aalactnun  •  3 
*  DO  REMOVE  INFORMATION 
Mpr*  •  .T. 

DO  RBXLE  Mora 
CLEAR 

M_APC  •  SPACE (4) 

9  6,0  TO  10,79  DOUBLE 

9  7,10  SAY  "Entar  tha  APC  Humbar  of  tha  Sactlon 
to  ranova  Ita 

axpandlturaa"  SET  M  APC  PICTURE 

•1999" 

9  9,10  SAY  "or  Prasa  Raturn  to  QOIT" 

READ 

IF  M  APC  ■  "  - 

Itora  -  .r. 

LOOP 

BNDIF 

USB  APC  INDEX  APC 
SEARCH-  UPPER (M_APC) 

LOCATE  FOR  APC-SEARCR 
IF  FOUNDO 
CLEAR 

t  6,0  TO  9,79  DOUBLE 
9  7,5  SAY  "Sactlon:  "♦SECTION 
9  7,35  SAY  "Sactlon  Coda:  "+S  CODE 
9  9,5  SAY  "Point  of  Contact J "TpOC 
9  9,35  SAY  ; 

"Talaphonat " ♦TRANSFORM (Talapbona, " (999) 999-9999") 

ELSE 

CLEAR 

9  6,0  TO  9,79  DOUBLE 

9  7,5  SAY  "APC  raquaatad  la  not  In  tba  Maatar 

Flla,  Plaaaa 

Try  again." 

77  CHR(7) 

9  15,0 

BAIT  "Praaa  Raturn  to  try  again..." 

LOOP 

ENDir 

M_MONTH  -  0 
9  14,0  TO  16,45 

9  15,5  SAY  "Entar  tha  MONTH  You  Niab  to  Dalata: 

OET  M_MONT8  PICTURE  "99"  RANGE  1,12 

READ 

USE  MOEXP  INDEX  MOEXP 

SET  FILTER  TO  FY-M_rY  .AND.  MONTH-M_MONTH 
OO  TOP 

LOCATE  FOR  APC-M_APC 
IF  FOUND  0 
CLEAR 

Mayba  •  "  " 

SET  FORMAT  TO  DELMOEXP 

READ 

CLOSE  FORMAT 
IF  UPPER (Mayba)  -  "Y" 

DELETE 

BNDIF 

ELSE 

9  20,0  CLEAR 

7  "Can't  find  tha  raquaatad  racord" 

77  CiR(7) 

BAIT  "Praaa  any  kay  to  try  again..." 

LOOP 

ENDIF 


YorH  -  -  - 
CLEAR 

9  5,1  SAY  "Pantanantly  raaova  racorda  Aarkad  for 
dalatlon  now? 

(Y/N)  "; 

OET  YorN  PICTURE  "1" 

9  7,1  SAY  * (Proeaaa  may  taka  a  faw  mlnutaa  to 
eomplata. .) " 

READ 

XF  YorH  4  "Y" 

SET  FILTER  TO 

9  5,0  SAY  "Plaaaa  atand  by  vhila  I  raindax  tha 

flla.  .* 

SET  TALK  ON 
RE INDEX 
SET  TALK  OFF 

ELSE 

SET  FILTER  TO 
Modala  -  0 

♦--Count  tha  numbar  of  raeecda  to  ba  dalatad 
7  "Counting...  Plaaaa  wait." 

COUNT  FOR  DELETED ()  TO  Nodala 
Pazmlaa  ■  "N" 

DO  BlILE  Paxmiaa  «  "N"  .AMD.  Nodala  >  0 
CLEAR 
7 

DISPLAY  APC,  FY,  MONTH,  EXPENSES  FOR  DELETED () 
7 

Paxialaa  ■  ■  " 

9  23,5  SAY  "OR  to  dalata  all  thaaa?  (Y/N) 

OET  Parmlaa  PICTURE  "I" 

READ 

• — IP  not  OK  to  dalata  all,  find  out  which 
XF  Parmlaa  f  "Y" 

RacNo  •  0 
9  20,0  CLEAR 

9  23,5  SAY  "Raeall  which  ona  (Racord 


Numbar) t 


"♦STR(RaeH0,  4) 


OET  RaeNo  PICTURE  "999999" 

READ 

XF  RaeNo  >  0  .AND.  RaoNo  <*  RECCOUNTO 
OOTO  RacNo 
IF  DELETED  0 
RECALL 

Nodala  •  Nodala  -  1 
ENDIF 
ELSE 

9  20,0  CLEAR 

9  23,5  SAX  "No  aueb  racord: 


7  CBR(7) 

BAIT 

ENDIF 

ENDIF 

ENDDO  (Parmlaa  and  No-dala) 

SET  TALK  ON 
CLEAR 

9  2,0  SAY  '  ' 

7  'PACKZNO  DATABASE  TO  REMOVE  RECORDS  HARKED  POR 
DELETION' 

PACK 

SET  TALK  orr 

SET  CONFIRM  OFF 
BAIT 

SET  CONFIRM  ON 

CASE  aalactnun  -  4 
*  DO  RIVIEB  INFORMATION 
USE  MOEXP  INDEX  MOEXP 
CLEAR 

M_MOHTH  •  0 

\  9  6,0  TO  9,79  DOUBLE 

9  7,15  SAY  "Entar  tba  Month  to  Raviaw"; 

\  OET  M_MONTB  PICTURE  "99"  RANOE  1,12 
READ 

*-Filtar  out  axtranaeua  information 

SIT  FILTER  TO  FY^  FY  .AND.  MONTB-M  MONTH 

00  TOP 

BR0B5B  NOAPPEND  NOMBNU 
SET  <^77 

BAIT 

SET  CONFIRM  ON 


ENDDO  T 
RETURN 

*  EOF:  BHBNU2.PRG 


•lONUa.PRO 


■ 


•  Author...!  BLBBRT  T.  BBAN  «  JOAM  ZIMaRMAK 

•  ra*0 . !  C2,14/ei9 

*  Copyright  fe)  ELRIPT  T.  SRAK  4  lOXN 

IZMamAV,  All  Rights  Rosurvud 

*  Kotos. . . .} 

OSB  Arc  IMDBX  APC 

Mt  »  ClR<17)<fCBRa»<)+CBR(217) 

DO  KBILB  .T. 

«  . — Dlsploy  MAU  options,  eontsrod  on  th«  sernon. 

•  draw  «oau  bosdor  and  print  haading 
M  ArC*«rACS<4) 

CLEAR 

f  2,  0  TO  14,79  DOUBLE 

I  3,12  SAT  [UfDATB  APC  INrORHATXON  T 
I  L  B] 

•  4,1  TO  4,7S  DOUBLE 

«  .^-display  datail  linas 
t  7,30  SAY  {1.  ADD  APC  IKTORMATIOH] 

•  B,30  SAY  (2.  CBAMOB  AFC  INTORMATION] 

f  9,30  SAY  (3.  RSVZBK  ALL  APC  IKTORHATZON] 

I  16,22  SAY  ”(  APC  is  tha  Account  Prooasslng  Coda  1” 

I  11,  30  SAY  *0.  EXIT' 

STORE  0  TO  salactnuM 

•  14,33  SAY  •  salact 

•  14,42  OBT  aalaetnua  PICTURB  "9"  RAMOB  0,3 
READ 

DO  CASB 

CASB  salactnua  •  0 
SET  BELL  ON 
SET  TALK  ON 
CLEAR  ALL 
RETURN 

CASE  salactnuM  -  1 
*  DO  ADO  INTORMATIOH 
Adding  >  .T. 

DO  NBZLB  Adding 
^—^Ask  for  naa  APC  to  add 
CLEAR 

CLOSE  rORKAT 

M_APC  •  SPACB(4) 

f”6,0  TO  6,79  DOUBLE 

€  7,15  SAY  "Entar  APC  Coda  -> 

GET  M^APC  PICTURE  "!999* 

I  19,15  SAY  "Prass  Enter  ("tRatt"]  to  raturn  to 

Menu" 

READ 

*''-Craata  lookup  variabla 
Search  •  UPPER <H_APC) 

nothing  antarad,  Laava  Program 
IP  Search  •  *  " 

EXIT 

BNDir 

**«8aa  if  APC  is  already  Stored 

SEEK  Search 

SET  rORKAT  TO  APC 

nana  Pound  Edit 
IP  POUND  <) 

CLEAR 

«  6,0  TO  6,79  DOUBLE 
#  7,15 

77  "APC  Coda  salactad  is  already  in  use. 
Please  try  again..." 

77  CERp) 

i  22,0 

BAIT 

LOOP 

EMDIP 

* — If  not  found.  Add  new  APC 
IP  .NOT.  rOUNDO 
APPEND  BLANK 
REPLACE  APC  KITH  M  APC 
READ 
ENDZP 

BMDDO 

f  5,0  SAY  "Please  stand  by  while  Z  relndex  the 

file, .- 

SET  TALK  ON 

REINDEX 

SET  TALK  OPP 

LOOP 

CLOSE  PORHAT 


CASB  selectnum  ■  2 
*  DO  CRAKGE  INPORMATION 
CLEAR 

Adding  •  .T. 

DO  KRlLE  Adding 

*'> — ^Ask  for  new  AFC  to  add 


change 


Menu" 


CLEAR 

CLOSE  PORMAT 
M  APC  >  SPACE  (4) 

|'‘6,0  TO  9,79  DOUBLE 

E  7,15  SAY  "Enter  the  APC  Code  you  wish  to 

GET  M_APC  PICTURE  "1999" 
t  6,15  SAY  "Press  Enter  ("tRett"]  to  return  to 


READ 

" — Create  lookup  variable 
Search  -  UPPER (H_APC) 


If  nothing  antarad,  Leave  Program 
IP  Search  «  "  " 

Adding  •  .P. 

LOOP 

EMDIP 


*— Sea  if  APC  is  already  Stored 

SEEK  Search 

SET  PORHAT  TO  APC 


""-If  name  Pound  Edit 


IP 


into  inactive 
PICTURE  "1" 


POUND  0 

M  APC8TATU8  -  "  - 
CLEAR 

•  6,0  TO  6,7  9  DOUBLE 

I  7,15  SAY  "Do  You  wish  to  put  this  APC  Code 
status  (Y/N):"  OBT  M_APC8TATUS 


READ 

•-  IP  KANT  TO  IHACTIVATI  APC,  JUST  PUT  A 

INACTIVE 

CODE  INTO  PILE 

*  ELSE  EDIT  THE  PILE  AS  USUAL. 


IP  H  APCSTATDS  »  "Y" 

REPLACE  STATUS  KITH  Z 

ELSE 

SET  PORHAT  TO  APC 
READ 

CLOS^  PORHAT 
ENDIP 

ELSE 

"•"Zf  not  found,  warn  user 
t  6,0  TO  6,79  DOUBLE 
«  7,15 

7  "Can't  Pind  the  APC  you  requested: 

",  Search 

77  CBR(7) 

NAZT 

ENDIP  <found) 


BNDDO 

CLEAR 

9  5, 0  SAY  "Please  stand  by  while  I  ralndax  tha 

file. ." 

SET  TALK  OH 
RE INDEX 
SET  TALK  OPP 
SET  CONFIRM  OPP 
BAIT 

SET  CONFIRM  ON 


CASE  salactnwB  ■  3 
•  DO  REVIEB  INTORMATIOH 

SET  SBLP  OPP 

OO  TOP 

BROWSE  NOAPPBND  NOMZNU 

SET  CONFIRM  OPP 

BAIT 

SET  rONPTPM  ON 


BNDCASI 

LOOP 

INDDO 

RETURN 

*  EOF:  BMEHU3.PR0 
'Z 


*  Program. . 

BIOBUS.RRO 
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*  Author...:  ELURT  T. 

*  r»»»# . >  02  •14/OR 

*  tloiif*...!  '•~|»yrl'jh» 

gXIMtRMAN,  ALL  Right*  1 

*  Not**. .  .  .  t 

*  R«««rv*4. i  ••Xuotnua 


. :  ELBERT  T.  EBAR  4  JOAN  ZlftaRNAN 
.  >  02  •14/9R 

.  I  '*''|>yr1gh»  |r>  1969.  RLRBRT  T.  EHAII  «  K^AN 

ALL  Right* 


SET  TALK  orr 
SET  BELL  orr 
SET  ESCAPE  orr 

SET  COIVriRM  W 

DO  WHILE  .T. 

•  -—Display  MRU  options,  eantarod  on  th«  scroan. 

•  draw  Manu  bordar  and  print  haadlng 
CLEAR 

f  2,  0  TO  14,79  DOUBLE 
t  3,26  SAY  [PRINT  REPORTS] 
t  4,1  TO  4,76  DOUBLE 

•  — -dlspl^  datall  Unas 

•  7,33  SAY  [1.  HONTBLY  REPORT] 

t  6,33  SAY  (2.  QUARTERLY  REPORT] 

•  9,33  SAY  [3.  rXSCAL  YEAR  REPORT  (RECAP)] 
t  10,33  SAY  [4.  PRINT  ORAPHS] 

t  12,  33  SAY  '0.  EXIT' 

STORE  0  TO  salactnuiB 
t  14,  33  SAY  "  salaet  " 

I  14,42  (SET  salaetnun  PICTURE  *9"  RANOt  0,4 
READ 

DO  CASE 

CASE  salactnum  ■  0 
CLEAR  ALL 
RETURN 


CASE  salaotnua  ■  1 

•  DO  MONTHLY  REPORT 

DO  BHBHU4_1 

MAZT 

SET  CONTIRM  ON 

CASE  salaetnun  •  2 

•  DO  QUARTERLY  REPORT 

DO  BMENU4  2 


WAIT 

SET  CONFIRM  ON 


CASE  salaetnun  ■  3 
•  DO  FY  REPORT 


NAIT 

SET  CeWFIRM  ON 


CASS  salaetnun  >  4 
•  DO  PRINT  GRAPHS 


WAIT 

SET  CONFIRM  OH 


BNDDO  T 
RETURN 

*  EOF:  aHBNU4.PR0 

'*2 


DO  BMXNU4  3 


DO  BNENU4  4 


SET  CONTI  PM  orr 


SET  CONFIRM  OFF 


SET  CONFIRM  OFF 


SET  CONFIRM  OFF 


•  Author...:  ELBERT  T.  SHAN  t  JOAN  ZIM4ERMAN 

•  Data . :  02/14/69 

•  Notlea...:  Copyright  (e)  1989,  ELBERT  T.  SHAM  t  JOAN 
ElfMERMAN,  All  Rights  Rasarvad 

•  Nota* . . . . r 

SET  TALK  OFF 

SET  BELL  orr 

SET  ESCAPE  OFF 
SET  CONFIRM  ON 
M_FY  •  0 
M  MO  •  0 
CLEAR 

14,  0  TO  9,79  DOUBLE 

•  7,15  SAY  "Entar  tha  Fiscal  Yaar  for  tba  report”; 

GET  M  FY  PICTURE  ”99" 


READ 

6  6,35  SAY  "Entar  tba  Month  for  tba  report”; 

GET  M  HO  rirn^PE  "‘>9"  RANGE  I,  12 

READ 

***  Restrict  output  to  salaetad  FY  and  salaetad  Month 

***  MONTHLY  REPORT  PRINTED  HERE  *** 

*  EOr:  fiMBNU4_l.PR0 


*  Progran. .: 

■mUE^E.PM 

*  Author...:  ELBERT  T.  SHAN  4  JOAN  ZXIMBRMAN 

*  Data . t  02/14/69 

*  Notice...:  Copyright  (e)  1969,  ELBERT  T.  SHAN  4  JOAN 
ZZIMERMAM,  All  Right*  Rasarvad 

*  Notes. . . . : 

SET  TALK  orr 
SET  BELL  OFF 
SET  ESCAPE  OFF 

SET  CONFIRM  ON 
M_rY  •  0 
H  QTR  -  0 
CLEAR 

66,  0  TO  9,79  DOUBLE 

t  7,15  SAY  "Enter  tha  Fiscal  Yaar  for  tba  report”; 

GET  M_FY  PICTURE  *99" 

READ 

i  8,15  SAY  "Enter  tha  Quarter  for  tha  report”; 

GET  M_QTR  PICTURE  "9"  RANGE  1,4 

READ 

**•  QUARTERLY  REPORT  PRINTED  HERE  *•* 

*  EOF:  BMBNU4_l.PRa 
^Z 


*  Progran. . i 

BlttNV4^3.PRO 

*  Author...:  ELBERT  T.  SHAN  4  JOAN  ZXI<t4ERMAN 

*  Data. . . . .:  02/14/89 

*  Notice...:  Copyright  (e)  1969,  ELBERT  T.  SHAN  4  JOAN 
ZIMMERMAN,  All  Right*  Ra*arvad 

*  Notes . . . . : 

SET  TALK  OFF 
SET  BELL  OFF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 
M_rY  -  0 

*  CLEAR  THE  SCREEN  TO  ACCEPT  THE  FY  INPUT 

*  DETERMINE  THE  FY  OF  THE  REPORT 
CLEAR 

6  6,0  TO  6,79  DOUBLE 

6  7,15  SAY  "Enter  tba  Fiscal  Yaar  for  tba  reports"; 

GET  M_rY  PICTURE  "99" 

READ 

DC  NHILE  .T. 

*  —-Display  menu  options,  cantered  on  tha  screen. 

*  draw  menu  bordar  and  print  beading 
CLEAR 

12,  0  TO  12,79  DOUBLE 

6  3,6  SAY  [FISCAL  YEAR  REPORTS] 

I  4,1  TO  4,76  DOUBLE 

*  - display  datall  lines 

6  7,33  SAY  [1.  FISCAL  YEAR  ALLOCATION  REPORT) 

9  6,33  SAY  [2.  FISCAL  YEAR  RECAP] 

9  10,  33  SAY  '0.  EXIT' 

STORE  0  TO  salaetnun 
9  12, 33  SAY  "  select 

9  12,42  GET  salaetnun  PICTURE  "9"  RANGE  0,2 
READ 

DO  CASE 

CASS  salaetnun  ■  0 
SET  BELL  ON 
SET  TALK  ON 
CLEAR  ALL 
RETURN 

CASE  salaetnun  -  1 
*  DO  ALLOCATION 

***  FY  ALLOCATION  REPORT  PRINTED  HERE 

***  SET  CONFIRM  OFF 

NAIT 
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StT  COMTIMl  ON 

CAAt  ••l*ctr)u»  ■  2 

•  u.>  txt  n»i»tT'’i  1.3 

***  FY  RECAP  REPORT  PRINTED  HERE  *** 

«IT  COHriKH  OFF 

WAIT 

SET  CONFZrai  ON 

KMOCASI 

BNDDO  T 
FETUKN 

•  BOFi  BMlM04_3.Flia 


*  FrogrM . .  t 

MSRV4_4.FM 

*  Author...!  BLBBAT  T.  4BAII  «  JOAN  2ZM<aBMXN 

*  . .  02/14/89 

*  Notie*...:  Copyrl9ht  (e)  1969,  BL8BRT  T.  SHAN  «  JOAN 
BUMBRMAM,  All  Right*  R«s«rv«d 

*  Not** _ t 

8BT  TALK  OFF 
4BT  BBLl.  OFF 
8BT  BSCAFB  OFF 
8BT  CONFIRM  ON 
M_FY  -  0 
M_QTF  •  0 
M^RANOE  •  0 

DO  NBILE  .T. 

*  'Display  manu  options,  csntarad  on  tha  scraan. 

*  draw  manu  bordar  and  print  haading 
CLEAR 

I  2,  0  TO  12,79  DOUBLE 

•  3.29  SAY  tPBlNT  ORAPHS] 

•  4, 1  TO  4, 78  DOUBLE 

*  ---display  datall  Ilnas 

•  7.24  SAY  (1.  PERCENT  SPENT  FOR  OUARTER  (BAR  GRAPH>) 

4  6,24  SAY  (2.  TREND  ORAPHS  (LINE  GRAPH}] 

4  10,  24  SAY  '0.  EXIT' 

STORE  0  TO  salaetnun 
4  12.33  SAY  "  salaet 

4  12,42  OET  salaetnun  PICTURE  *9"  RANGE  0,3 
READ 


DO  CASE 

CASE  salaethum  ■  0 
SIT  BELL  ON 
SIT  TALK  OH 
CLEAR  ALL 
RETURN 

CASE  salaetnun  ■  1 

*  DO  PERCENT  SPENT  FOR  QTR  (BAR  GRAPH} 

*  Claar  scraan  for  FY  and  QTR  Input 
CLEAR 

46,0  to  9,79  DOUBLE 

47,15  SAY  "Bntar  tha  riscal  Yaar  of  tha 
Expandltura: 

GET  M_FY  PICTURE  "99” 

READ 

4  6,15  SAY  "Entar  tha  Quartar  to  Ravlaw”; 

GET  M  QTR  PICTURE  ”9”  RANGE  1,4 
READ  *“ 

***  DETERMINE  EXPENDITURE  BY  SECTION  FOR  EACH 


GET  M_FY  PICTURE  "99" 

READ 


TOTAL  RT.L  SE'^TION  EXPFNPTTnRFn  RY  ►♦’'NTH 
DEitijitiie  DfiM  iiirni  rxieiH-ir-ir  r  i  t..  n 
MONTE  OF  FY.  ALSO  GRAPE  TOTAL  ALLOCATION  FOR 
DEPARTMENT  FOR  EACE  QUARTER. 

***  PRINT  YEARLY  TREND  LINE  GRAPH  HERE 

a  *  * 


*  DO  LONG  TERM  TREND  (TREND  GRAPE} 

LOCATE  ALL  DATA  FOR  CURRENT  FISCAL  YEAR,  AND 

PREVIOUS  FISCAL  YEARS  UP  TO  TIB  TWO  YEARS 
FROM  CURRENT  YEAR 

•••  TREND  ON  MONTIS  EXPENDITURES,  DISPLAY  a 

ALLOCATIONS  FOR  TBOSE  YEARS 

INDIVIDUAL  AFC  EXPENDITURES  ARE  TOTALED  TO  GET 

A 

DEPARTMENT  WIDE  PICTURE 

***  PRINT  LCWG  TERM  TREND  GRAPH  HERE  *** 


SET  CONFIRM  OFF 
BAIT 

SET  CONFIRM  ON 

BHDCASE 

ENDDO  T 
RETURN 

*  lOFt  BPIENUS.PRO 


SECTION  FOR  THE  QUARTER  SELECTED,  BIS  FIGURE 
COULD  BE  A  PARTIAL  OUTLOOK  FOR  TEE  CUPRENT 
QUARTER  COMPARE  TO  CURRENT  SECTION' S  ALLOCATION 
AND  DETERMINE  PERCENTAGE  SPENT 

***  PERCENT  SPENT  FOP  QMAPTF.P  CPA^H  HFPE 

SET  CONFIRM  OFF 
BAIT 


READ 

SET  CONFIRM  ON  • 

CASE  salaetnun  •  2 
*  DO  TREND  (LINE  GRAFS) 

M_FY  •  0 

*  Claar  Scraan  for  FY  Input 
CLEAR 

46,0  to  8,79  DOUBLE 

47,15  SAY  "Entar  tha  Fiscal  Yaar  of  tha  Raport:"; 
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APPENDIX  D.  EQUIPMENT  PROGRAMS 


«MU  or  MOOMMi 

MMO.rRO 
■MBMUl.rKO 
INBII01_2 .  rKO 
Biai«01_).PIl9 
naiio2 .  PRO 
Il«lf02  2. PRO 

tMUfUa .  PRO 
BI«UI09_1 .  PRO 
I»«1I03_2 .  PRO 
UU  2  l.PRO 
IMBNdI_S  .  PRO 
IMBMU3_4 .  PRO 
IM3  4  l.PRO 
KMimT?_5.PRO 
IHIND4 . PRO 


t  14,42  OIT  Ml»etAUM  PICTTTRl  ”9”  RANOt  0,4 
RtAD 

DO  CAPt 

CAPI  ■•IttctnuM  •  0 
PIT  PILL  OH 
PIT  TALK  Oil 
CLIAR  ALL 
RITUFM 

CAPE  ••Isetnun  •  1 
*  DO  OPDATt  IODXPHIIIT  LXPTIHO 

DO  IHUIDl 

SIT  COHTIRH  Orp 
STORE  '  '  TO  llpit_#Ub«t 
#  23,0  SAT  'Pr««c  any  kay  to  eontinua.. 
walt_aub«t 

READ 

SET  CONPXRM  ON 


OXPCXAXMUl 


CASE  ••laetnum  •  2 
•  DO  OPDATI  PRIORITXtS 


TAo  purpose  of  this  programming  coda  is  to 
facilitata  tha  vndarstanding  of  the 
raquiramanta  prasantad  in  Chapter  5  of  this 
thasis.  Tha  nature  of  this  project  precludes 
It  actual  implementation  in  DBASE  IJI+.  To 
fully  implement  the  requirements  the  system 
designer  will  need  a  full  range  of  capabilities 
that  does  not  currently  exist  in  DBASE  III-*-. 

DBASE  111+  served  as  the  modeling  tool  by 
rhich  the  screens  were  generated  and  vhere 
necessary,  specific  code  was  written  to 
illustrate  a  point.  Tha  actual  working  code 
merely  acts  as  a  shell  in  rhich  to  run  the 
menus.  A  ciose  analysis  of  the  program  code  can 
facilitate  implementation  in  a  more  suitable 
language,  i.e.,  PARADOX,  rhich  can  support  the 
graphics  and  high  level  relationships  involved 
in  the  various  databases.  Khere  the  actual 
requirements  process  may  appear  to  be  unclear, 
comments  were  added  within  the  code  to  explain 
these  areas  to  the  designer. 

*  Vrogiam. . 

*  Author...:  ILBIRT  T-  SIAN  «  JOAH  SUeaRHAN 

*  Data . :  02/16/S9 

*  Notlca...:  Copyriobt  (c)  1989,  All  Rights  Raaarvad 

*  Motaa _ 

SIT  TALK  orr 
SIT  BILL  orr 
SIT  STATUS  orr 
SET  iscAPi  orr 
SIT  C<»friRM  OH 


DO  BMINU2 

SET  COHrXRH  OPP 
STORE  '  '  TO  aalt^aubat 
•  23,0  SAY  'Pra8a~any  kay  to  eontlnua.. 
wait  aubat 

~  READ 

SET  CORPIRM  OH 

CAPI  aalactnua  ■  3 

•  DO  PRXHT  REPORTS 

DO  BHBNU3 

SIT  CONPXRM  orr 

STORE  '  '  TO  aait^aubat 
f  23,0  SAY  'Praaa''any  kay  to  eontlnua.  . 
walt^aubat 

"  READ 

SET  CONPXRM  OH 

CASE  aalactnum  •  4 

*  DO  ARCIIVI  SXSTORXCAL  DATA 

DO  INBRU4 

SET  CONFIRM  OPP 
STORE  '  '  TO  walt_aubat 
9  23,0  SAY  'Praaa  any  kay  to  eontlnua.. 
wait^aubat 

READ 

SET  CONPXRM  ON 

ENDCASE 

ENDDO  T 
RETURN 

*  EOPt  EMENU.PRQ 


DO  NHTLE  .T. 

*  ..-Diaplay  laanu  options,  cantarad  on  tha  scraan. 

*  draw  aanu  bordar  and  print  haadinq 
CLEAR 

9  2,  0  TO  14,79  DOUBLE 

9  3,13  SAY  [DIPARTHENT  OF  FAMILY  PRACTICE  PLANNED 
EQUIPMENT  SYSTEM) 

9  4,1  TO  4,78  DOUBLE 

*  - display  datall  llnat 

9  7,27  SAY  {1.  UPDATE  EQUIPMENT  LISTING) 

9  8,27  SAY  [2.  UPDATt  PRIORITIES) 

9  9,27  SAY  t3.  PRINT  REPOPTS) 

9  10,27  SAY  (4.  ARCIIVI  RISTORXCAL  DATA) 

9  12,  27  PAY  '0.  EXIT' 

STORE  0  TO  aalactnum 
9  14,33  SAY  "  aalact 


*  Preoram. . 

nmui.PRO 

•  Author...:  JOAN  SIlOaRHAN  4  ELBERT  SRAM 

•  Data . ;  02/18/89 

*  Notlea...:  Copyright  (c)  1989,  JOAN  ZIieaRMAN 
SIAN,  All  Right!  Raaarvad 

SET  TALK  orr 
SET  BELL  OPP 
SET  STATUS  OFF 
SET  ESCAPE  orr 
SET  CONFIRM  OH 
USE  EQUIP 

DO  NRILE  .T. 


.  '  GET 


OET 


OET 


’  OET 


ELBERT 
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*  ->-Dlaplay  M«nu  options,  c«nt«r*d  on  tb«  soroon. 

*  draw  Mnu  bordar  and  print  haadln^ 

CLtAK 

*  2.  0  TO  14, 79  DOUBLE 

#3,17  SAY  lOrDATE  PPOCUFEMENT  LIST 

1  M  0] 

*  4,1  TO  4,78  DOUBLE 

*  —display  datail  llnaa 

9  7,30  SAY  [1.  ADD  EQUIPMENT  IKTOFMATION] 

9  8,30  SAY  (2.  CBANOE  EQUIPMENT  DATA] 

9  9^30  SAY  (3.  REMOVE  EQUIPMENT  ENTRY] 

9  10,30  SAY  [4.  RSVIBtl  EQUIPMENT  LIST] 

9  12,  30  SAY  '0.  EXIT' 

STORE  0  TO  salaetnun 
9  14,33  SAY  ”  aalaet 

9  14,42  GET  aalactnuM  PICTURE  "9"  RANGE  0,4 
READ 

DO  CASE 

CASE  aalaetnum  ■  0 
RETURN 

CASE  aalaetnim  •  1 

*  DO  ADD  INTORMATION 

SET  CONFIRM  OFF 

SET  FORMAT  TO  EMXNU1_1 

APPEND  BLANK 

*TBI5  COMPUTES  THE  EXTENDED  PRICE 
REPLACE  EXYTRICE  BITS  QTY  •  ONITPRICE 
CLOSE  FORMAT 

•VERIFY  TEAT  TEE  CODE  NUMBER  GIVEN  IS  NOT  A 

DUPLICATE 

*1F  XT  IS,  NOTIFY  USER  AND  ALLOW  TSEM  TO  CHANGE  THE 
•NUMBER  WITHOUT  REEOXTINQ  THE  COMPLETE  INFORMATION 
•THEN  REPLACE  TEE  OLD  CODE  NUMBER  WITH  THE  NEW 

NUMBER 

STORE  '  '  TO  walt^aubst 

9  23,0  SAY  'Praas  any  kay  to  continua...'  GET 
walt___aubat 

READ 

SET  CONFIRM  ON 

CASE  salaetnun  «  2 

*  DO  CHANGE  INFORMATION 

DO  EMENUl  2 


SET  CONFIRM  OFF 
STORE  '  '  TO  walt^subst 

9  23,0  SAY  'Praia  any  kay  to  continua...'  GET 
wait^aubst 

READ 

SET  CONFIRM  ON 

CASE  salaetnun  ■  3 

•  DO  REMOVE  INFORMATION 

DO  EMENU1_3 
SET  TALK  OFF 
SET  CONFIRM  OFF 
STORE  '  '  TO  walt^^aubst 

9  23,0  SAY  'Praia  any  kay  to  continua...'  GET 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  salaetnun  *  4 

•  DO  REVIEW  INFORMATION 
M  SECT  -  " 

CLEAR 

9  6, 0  TO  8, 79  DOUBLE 

9  7,15  SAY  "Entar  tba  laction  coda  of  tba  aaction 
to  raviaw”; 

GET  M  SECT  PICTURE  "EXX" 

READ 

SET  HELP  OFF 

SET  FILTER  TO  8ECTCODE«M_SECT 
GO  TOP 

BROWSE  NOAPPEND  NOMENU 

SET  FILTER  TO 

CLEAR  MEMORY 

SET  CONFIRM  OFF 

STORE  '  '  TO  waitiubst 

9  23,0  SAY  'Praas  any  kay  to  continua...'  GIT 
walt_subst 

READ 

SET  CONFIRM  ON 

ENDCASE 

ENDDO  T 
RETURN 

•  EOF:  EMENUl. PRO 
*» 


•  Pro9ran. . 

■l■lrUl_2.PR0 

*  Author....*  JOAN  ZIMMERMAN  1  ELBERT  SHAN 

*  Data. . . . 02/16/99 

•  Notlea...:  Copyright  (c)  1989,  JOAN  ZIIMBRHAN  a  ELBERT 
SIAN,  All  Rights  Rasarvad 

SET  TALK  OFF 
SET  BELL  OFF 
SET  STATUS  OFF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 
USE  EQUIP 
DO  WHILE  .T. 

•  - Display  nanu  options,  eantarad  on  tba  scraan. 

•  draw  nanu  bordar  and  print  haading 
CLEAR 

92,  0  TO  12,79  DOUBLE 

9  3,23  SAY  [CBANOE  PROCUREMENT  DATA] 

9  4,1  TO  4,78  DOUBLE 

•  - display  datail  linas 

9  7,27  SAY  [1.  BY  EQUIPMENT  CODE  NUMBER) 

9  8,27  HAY  {2,  BY  SECTION  CODE] 

9  10,  27  SAY  '0.  EXIT' 

STORE  0  To  salaetnun 
9  12,33  SAY  ”  salaet 

9  12.42  GET  salaetnun  PICTURE  "9"  RANGE  0,2 
READ 

DO  CASE 

CASE  salaetnun  •  0 
RETURN 

CASE  salaetnun  ■  1 

•  DO  BY  EQUIPMENT  CODE  NUMBER 

CLEAR 

M_EQ  -  0.0 

96,0  TO  8,79  DOUBLE 

9  7,15  SAY  "Intar  tba  Equlpnant  Coda  Nunbar:"; 

GET  M  EQ  PICTURE  ’*9999.99'* 

READ 

IF  M  BQ  •  0.0 
LOOP 
ENDIF 
GO  TOP 

LOCATE  FOR  EQCODE»M  EQ 
SET  FORMAT  TO  EMENUT  1 
READ 

CLOSE  FORMAT 

SET  CONFIRM  OFF 

STORE  '  '  TO  wait^subst 

9  23,0  SAY  'Praia  any  kay  to  continua...’  GET 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  Salaetnun  ■  2 

•  DO  BY  SECTION  CODE 

CLEAR 
M  SECT  -  " 

96,0  TO  8,79  DOUBLE 

97,15  SAY  "Bntar  tba  Saction  Coda  for  saction 
naading  changas:”; 

rZT  M_SECT  PICTURE  "AAA" 

READ 

IF  M_5ECT  -  "  " 

LOOP 

ENDIF 

RECORD  -  "  " 

00  TOP 
CLEAR 

LI.'^T  ALL  EQCOPE..SErTCODE.REQPATE,DBSCPIPT.Pr.QTYPE; 
FOR  SECTCODE-M_SECT 

921.10  SAY  "Bntar  tba  Racord  Nunbar  of  tha  racord; 

to  ebanga:"  GET  RECORD 
READ 

GOTO  4RECORD 

SET  FORMAT  TO  EMENUl_l 

READ 

CLOSE  FORMAT 

SET  CONTI PM  OFF 

STORE  '  '  TO  walt_sub»t 

9  23,0  SAY  'Praia  any  kay  to  continua...’  GET 
wait  lubit 


UAD 

SIT  COMTIFM  ON 

BMDCASK 

SMDDO  T 
MTUIW 

*  tort  IHtNUl_2.rtO 


*  Proqran. . t 

•  Author...!  JOAN  ZIIMKRMAM  k  ELBERT  SRAM 

*  Dat« . :  03/16/89 

•  MotlM...!  Copyright  (C)  1989,  JOAN  ZIHMBRHAN  C  ELBERT 
SBAN,  All  Rights 

SET  TALK  orr 
SET  BELL  orr 
SET  STATUS  OTr 
SET  ESCAPE  orr 

SET  CmriRM  0» 

USE  EQUIP 
STIUATIT  -  .T. 

DO  WBILE  STIUATIT 

*  ‘Dlsplhy  m«nu  options,  csntorod  on  th«  scrssn. 

*  drsw  »«nu  bordor  and  print  hosding 
CLEAR 

•  2,  0  TO  12,79  DOUBLE 

•  3,17  SAY  (REHOVE  PROCUREMENT  ENTR 
Yl 

#  4,1  TO  4,78  DOUBLE 

*  - display  datall  Unas 

9  7,27  SAY  [1.  BY  EQUIPMENT  CODE  NUKBZRl 

9  8,27  SAY  [2.  BY  SECTION  CODE] 

9  10,  27  SAY  '0.  EXIT' 

STORE  0  TO  salaetnuiB 
9  12,33  SAY  "  salact 

9  12,42  OET  salaotnum  PICTURE  "9''  RANGE  0,2 

READ 

DO  CASE 

CASE  salactnun  ■  0 
RETURN 

CASE  salactnun  >  1 

•  DO  BY  EQUIPMENT  CODE  NDMBER 

ANSWER  •  -  - 
CLEAR 

M^EQ  •  0,0 

96,0  TO  8,79  DOUBLE 

9  1,18  SAY  "Entar  tba  Bgulpnant  Coda  Numbart"; 

OET  M  EQ  PICTURE  "9999. PS- 

READ 

If  no  nunbar  raturn  to  nanu  •• 

IP  M_E0  -  0,0 

8TILLATIT  •  .F. 

LOOP 

ENDir 

**  Look  for  aqulpraant  coda  ** 

LOCATE  rOF  EQCODE-M_EQ 
CLEAR 

DISPIAY  EQCODE, SECTCODE, REQDATE, DESCRIPT, REQTYPE 
7 

WAIT  "REMOVE  TBIS  RECORD?  (Y/N) "  TO  ANSWER 
IF  UPPER (ANSWER)  •  "Y" 

DELETE  RECORD  RECNO < ) 

BNDir 

SET  TALK  ON 
97,15 

RECALL  ALL 

WAIT  "This  Is  whara  tha  pack  would  go" 

SET  TALK  orr 

SET  CONTI RM  OPT 

STORE  '  '  TO  wait  subst 

9  23,0  SAY  'Prasf  any  kay  to  contlnua...'  GET 
walt_subst 

READ 

SET  CONTIRM  ON 

CASE  salactnun  ■  2 

*  DO  BY  SECTION  CODE 

ANSWER  •  "  " 

CLEAR 

M^SECT  -  - 

96. 0  TO  8. 79  DOUBLE 

*7,15  SAY  "Entar  tha  Section  Coda  for  delations:"; 


READ 

RECORD  -  " 

OO  TOP 
clear 

LIJT  ALL  EQCODE.  SECTCOPE.  RfOTATE, DESCRIPT.  rrcr''f  r  ; 
POR  SECTCODE^^SECT 

921.10  SAY  "Enter  tha  Record  Musibar  of  tba  record; 

to  raaova:"  OET  RECORD 
READ 

OOTO  tRECORD 
CLEAR 

DISPLAY  SQCOOS, SECTCODE, REQDATE, DESCRIPT, REQTYPE 
7 

WAIT  "REMOVE  TBIS  RECORD?  (Y/N)”  TO  ANSWER 
IP  UPPER (ANSWER)  -  ”¥" 

DELETE  RECORD  RECNO ( ) 

EHDir 

SET  TALK  ON 
9  7,15 
RECALL  ALL 

WAIT  "This  Is  where  tba  pack  would  go  " 

SET  TALK  orr 

READ 

CLOSE  rORMAT 
SET  cowriRM  orr 

STORE  '  '  TO  walt_^subst 

•  23,0  SAY  'Prass  any  kay  to  continue...'  GET 
walt^aubst 

READ 

SET  CONTIRM  ON 

ENDCA8E 

ENDDO  T 
RETURN 

•  tor :  tMENUl_2  .  PRG 
-'2 


*  Progran. . t 

BOMUE.PRO 

*  Author...!  JOAN  ZXM4ERMAN  «  ELBERT  8RAW 

•  Data . I  02/17/89 

•  Notice...!  Copyright  (e)  1989,  JOAN  ZXhtaRMAN  «  ELBERT 
SRAW,  All  Rights  Reserved 

SET  TALK  orr 
SET  BELL  OPP 
SET  STATUS  OfP 
SET  ESCAPE  orr 
SET  CONTIRM  ON 
USE  EQUIP 
DO  WHILE  .T. 

*  -—Display  nanu  options,  cantarad  on  tha  screen. 

*  draw  nanu  border  and  print  beading 
CLEAR 

9  2,  0  TO  12,79  DOUBLE 

9  3,17  SAY  [UPDATE  PRIORITIBS/STATU 
S] 

9  4.1  TO  4,78  DOUBLE 

*  - display  datall  Unas 

9  7,32  SAY  (1.  UPDATE  PRIORITIES] 

9  8,32  SAY  [2.  UPDATE  STATUS) 

9  10.  32  SAY  '0.  EXIT' 

STORE  0  TO  salactnun 
9  12,33  SAY  "  select 

9  12,42  GET  salactnun  PICTURE  "9"  RANGE  0,2 
READ 

DO  CASE 

CASE  salactnun  ■>  0 
RETURN 

CASE  salactnun  ••  1 

•  niraT?  rPT'^PTTiE.s 

DO  BMEHU2_1 

SET  CONTIRM  OFF 
STORE  '  '  TO  walt^subst 

9  23,0  SAY  'Press  any  kay  to  continue...'  GET 
walt_subst 

READ 

SET  CONFIRM  ON 

CASE  salactnun  ■  2 

*  DO  UPDATE  STATUS 


GET  M_8ECT  PICTURE  "9!AAA' 


DO  EMENUr  2 


SET  CONrXEH  OFF 
STOKE  '  '  TO  w«it_subst 

•  S),0  SAY  'Fr*««  any  eont.lnua. . . '  QtT 

wait  aiibft 

READ 

SET  CONFIKM  ON 

EMDCASE 

BMDDO  T 
RSTtJRN 

*  EOF:  EMENUS.PRO 
*E 


*  Program. . t 

*  Author...:  JOAN  ZIIMBRMXN  «  ELBERT  SBAfV 

*  Data . :  02/16/89 

*  Notiea...:  Copyrioht  (e)  1989,  JQRM  ZltMERMEM  «  ELBERT 
SEAR,  All  Riobts  Rasarvad 

SET  TALK  OFF 
SET  BELL  OFF 
SET  STATOS  OFF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 
058  EOOIP 
DO  RBILE  .T. 

*  Dlaplay  nanu  options,  cantarad  on  tha  acraan. 

*  draw  nanu  bordar  and  print  haadin^ 

CLEAR 

€  2,  0  TO  14,79  DOUBLE 

9  3,24  SAY  {UPDATE  PRIORITIES) 

(  4,1  TO  4,78  DOUBLE 

*  - display  datall  llnas 

9  7,31  SAY  [1.  MEDCASE  lOUIPMENT) 

9  8,31  SAY  [2.  CEEP  EQUXPKENT) 

9  9,31  SAY  [3.  CAPR  EQUIPMENT] 

9  10,31  SAY  [4.  OTBBR  EQUIPMENT] 

9  12,  31  SAY  '0.  EXIT' 

STORE  0  TO  aalaetnun 
9  14,33  SAY  "  aalact  " 

9  14,42  SET  salaotnun  PICTURE  "9"  RANOE  0,4 
READ 

DO  CASE 

CASE  aalaetnun  •  0 
RETURN 

CASE  aalaetnun  •  1 

*  DO  MEDCASE  EQUIPMENT 
CLEAR 

SET  FILTER  TO  RBQTYPE»"MEOC’’ 

OO  TOP 

BRONSE  FIELDS 

EQCOOE.REQTYPE, 8ECTCODE, DCSCRIPT, URGCODE, PRIORITY, 

QTY, UNI TP RICE 
SET  FILTER  TO 
SET  CONFIRM  OFF 
STORE  '  '  TO  walt_aubst 

9  23,0  SAY  'Praaa  any  kay  to  contlnua...'  GET 
walt_aubat 

READ 

SET  CONFIRM  ON 

CASE  aalaetnun  •  2 

*  DO  CEEP  EQUIPMENT 

CLEAR 

SET  FILTER  TO  REQTYPE-"CEEP" 

OO  TOP 

BRONSE  FIELDS 

EQCODE , REQTYPE, SECTCODE , DESCRIPT, URGCODE , 

PRIORITY, QTY, UNITPRICE 
SET  FILTER  TO 

SET  CONFIRM  OFF 
STORE  '  '  TO  walt_aubat 

9  23,0  SAY  'Praaa  any  kay  to  contlnua...'  GET 
walt^aubat 

READ 

SET  CONFIRM  ON 

CASE  aalaetnun  ■  3 

*  DO  CAPR  EQUIPMENT 

CLEAR 

SET  FILTER  TO  REOTYPE«"CAPR" 

OO  TOP 

BRONSE  FIELDS 


EQCODE , REQTYPE , SECTCODE , DESCRXPT, UROCODE , 
PRIORITY, QTY, UNITPRICE 
SET  FILTER  TO 

SET  CONIIRM  OFF 
STORE  '  ‘  TO  walt_aubat 

9  23,0  SAY  'Praaa  any  kay  to  continue...'  OET 
walt_aubat 

READ 

SET  CONFIRM  ON 

CASE  aalaetnun  ■  4 
•  DO  OTBER  EQUIPMENT 

CLEAR 

SET  FILTER  TO  REQTYPE-"OTHE- 
00  TOP 

BRONSE  FIELDS 

EQCODE,  REQTYPE,  SECTCODE,  DESCRIPT,  0RG<.0DB, 
PRIORITY,  QTY,  UNITPRICE 
SET  FILTER  TO 

SET  CONFIRM  OFF 

STORE  '  '  TO  walt_aubat 

9  23,0  SAY  'Praaa  any  kay  to  eontlnua...'  OET 
walt^aubat 

~  READ 

SET  CONFIRM  ON 

BNDCASE 

BNDDO  T 
RETURN 

*  EOF:  EMBHU2.PR6 
'‘Z 


*  Pro^ran..: 

■HBIU2^2.PRe 

•  Author...:  JOAN  SIMMERMkN  4  ELBERT  SHAW 

•  Data . j  02/17/89 

*  Notiea...:  Copyrlsht  <e]  1989,  JQkN  ZUNURHAN  4  ELBERT 
SEAN,  All  Right#  raaarvad 

SET  TALK  OFF 
SET  BELL  OFF 
SET  STATUS  OFF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 
USB  EQUIP 

DO  NBZLE  .T. 

*  •••Dlaplay  nanu  optlona,  eantarad  on  tha  acraan. 

*  draw  nanu  bordar  and  print  heading 
CLEAR 

9  2,  0  TO  12, 79  DOUBLE 
9  3,28  SAY  [UPDATE  STATUS) 

9  4,1  TO  4,78  DOUBLE 

*  — •dlaplay  datall  llnaa 

9  7,31  SAY  [1.  BY  EQUIPMENT  CODE] 

9  8,31  SAY  [2.  BY  SECTION  CODE] 

9  10,  31  SAY  '0.  EXIT' 

STORE  D  TO  aalaetnun 
9  12,33  SAY  "  aalact 

9  12,42  OET  aalaetnun  PICTURE  "9"  RANGE  0,2 

READ 

DO  CASE 

CASE  aalaetnun  •  0 
RETURN 

CASE  aalaetnun  ■  1 
*  DO  BY  EQUIPMENT  CODE 

CLEAR 

M_E0  -  0.0 

96,0  TO  8,79  DOUBLE 

9  7,15  SAY  "Pntar  tha  Equlpnant  Coda  Numbar:”; 
GET  M  EQ  riCT'TE  •■!>??•,».  o’*” 

READ 

IF  M  EQ  -  0.0 
LOOP 
EHDIF 
CO  TOP 

LOCATE  FOR  EQCODE -M^EQ 
SET  FORMAT  TO  EMENU2_2 
READ 

CLOSE  FORMAT 

SET  CONFIRM  OFF 

STORE  '  '  TO  walt_aub8t 

9  23,0  SAY  ' Prasa  any  kay  to  contlnua...'  OET 
walt_aubat 

READ 
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SIT  CONrilM  OH 


CA8B  ••lactnuM  >  2 

•  DO  Dt  SEVTION  O^DE 

CLIAH 

M^SICT  •  "  " 

#6,0  TO  8, 79  DOOBLE 

#7,15  SAY  "lftt*r  th«  Section  Cod*  for  STATUS 

updat** : 

OBT  M_SBCT  PICTURE  "AAA" 

READ 

ir  M_SBCT  -  "  " 

LOOP 

BRDir 

RECORD  •  "  • 

00  TOP 
CLEAR 
LIST  ALL 

BQCOOE, SBCTCODB, RBODATB, DBSCRIPT, RBQTYPB, STATUS; 

POR  SBCTCOOE»H_SECT 

#21,10  SAY  *Bnt*r  th*  Roeord  Hunbor  for  STATUS 

updat** i 

OET  RECORD 

READ 

GOTO  t RECORD 

SET  PORHAT  TO  EMENU2_2 

READ 

CLOSE  PORMAT 

SET  CMIPIRH  OFF 
STORE  '  '  TO  wait_*\4bat 

#  23,0  SAY  'Prasa  any  kay  to  continua,..'  GET 
walt_^aubat 

READ 

SET  COHPXRM  OH 

EHDCASE 

BKDDO  T 
RETURN 

*  BOP:  CKENU2  2. PRO 
'•E  * 


CASE  aalactnuitt  •  2 

*  DO  CATBOORY/STATUS  REPORTS 
DO  EMEIfU3  2 

SET  CCHFIRM  OFF 
STORE  '  '  TO  walt_aubrt 

#  23,0  SAY  'Praaa  any  kay  to  contlnu*...'  OBT 
wait_aubat 

READ 

SET  CONFIRM  ON 

CASE  aalactnuA  ■  3 

*  DO  PRIORITY  HORXSBEET  REPORT 

DO  EMENU3  3 

SET  CONFIRM  OFF 

STORE  '  '  TO  walt_aubat 

0  23,0  SAY  'Praaa  any  kay  to  contlnu*...'  OET 
«*alt_aubat 

READ 

SET  CONPIRH  ON 

CASE  aalaetnun  •  4 

*  DO  BISTORICAL  PILE  REPORTS 
DO  EMEMU3_4 

SET  CONPIRM  OFF 
STORE  '  '  TO  ifalt_aubat 

#  23,0  SAY  'Praaa  any  kay  to  eontlnua...'  OET 
walt___Bubat 

READ 

SET  CONFIRM  OH 

CASE  aalactnuia  *  5 
»  DO  EXPORT  TO  FILE 

DO  BMSND3_5 

SET  CONFIRM  OFF 

STORE  '  '  TO  walt_a«b*t 

#  23,0  SAY  'Praaa  any  kay  to  eontlnua...'  GET 
walt^aubat 

READ 

SET  CONFIRM  OH 

EHDCASE 


*  Prooram. , : 

Bonrus.pRO 


EHDDO  T 
RETURN 

•  EOF:  EMEMU3.PRG 


*  Author...:  JOAN  ZIMMERMAN  (  ELBERT  SBAN 

*  Data . .  02/16/89 

*  Hotlea...:  Copyright  (e)  1969,  JOAN  ZIMMERMAN  4  ELBERT 
SBAN,  All  Rights  Raaarvad 

SET  TALK  OFF 
SET  BELL  OFF 
SET  STATUS  OFF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 

DO  WHILE  .T. 

#  --'Display  nanu  options,  cantarad  on  tha  scraan. 

#  draw  nanu  bordar  and  print  haadinq 
CLEAR 

#  2,  0  TO  15,79  DOUBLE 

#  3,28  SAY  (PRINT  REPORTS) 

#  4,1  TO  4,78  DOUBLE 

#  - display  datall  llnas 

#  7,27  SAY  (1.  DEPARTMENT  REPORTS] 

#  8,27  SAY  (2.  EQUIPMENT  TYPE  REPORTS] 

9  9,27  SAY  (3.  PRIORITY  WORKSHEETS) 

#  10,27  SAY  [4.  BISTORICAL  FILE  REPORTS] 

#  11,27  SAY  (5.  EXPORT  FILES  TO  SPREADSHEET] 

#  13,  27  SAY  '0.  EXIT' 

STORE  0  TO  aalaetnum 

9  15,33  SAY  "  aalact 

9  15,42  OET  aalaetnum  PICTURE  "9"  RANGE  0,5 

READ 

DO  CASE 

CASE  aalaetnum  •  0 
RETURN 

CASE  salactntin  ■  1 
*  DO  DEPARTMENT  REPORTS 

DO  EI«NU3_1 

SET  CONFIRM  OFF 
STORE  '  '  TO  w*lt_*ubst 

9  23,0  SAY  'Press  any  kay  to  eontlnua...'  OET 
walt_Bubst 

READ 

SET  CONFIRM  ON 


•  Program..: 

BBIIU3_l.PRO 

*  Author...:  JOAN  ZZ»MBRMAN  4  ELBERT  SHAW 

•  Data . :  02/17/89 

*  Notlea...:  Copyright  (e)  1989,  JQRN  ZltMERMRN  4  ELBERT 
SHAN,  All  Rights  Raaarvad 

SET  TALK  OFF 
SET  BELL  OFF 
SET  STATUS  OFF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 
USE  EQUIP 

DO  WHILE  .T. 

*  - Display  menu  options,  cantarad  on  tb*  scraan. 

*  draw  menu  bordar  and  print  beading 
CLEAR 

9  2,  0  TO  13,79  DOUBLE 

9  3,23  SAY  (DEPARTMENT  REPORTS] 

9  4,1  TO  4,78  DOUBLE 

*  — "display  datall  llnas 

9  7,32  SAY  (1.  BY  COST) 

9  8,32  SAY  [2.  BY  URGENCY] 

9  9,32  SAY  [3.  BY  STATUS  CODE] 

9  11.  32  SAY  '0.  EXIT' 

STORE  0  TO  aalaetnum 
9  13,33  SAY  "  select 

9  13,42  OBT  aalaetnum  PICTURE  "9"  RANGE  0,3 

READ 

DO  CASE 

CASE  salactnum  ■  0 
RETURN 

CASE  salactnum  ■  1 
*  DO  BY  COST 


*****  Bat  Indaa  to  eoat  aort  and  Print  report  bare 


SIT  coMrim  orr 

STOIE  '  •  T?  walt_»ubst 

6  23,0  SAY  'Pr«as  any  k«y  to  eontlnu*...'  OIT 
w«it_«ttbat 

RIAD 

SIT  CONPZfM  ^ 

CASl  ••loet&um  •  2 
*  OO  BY  UBOBNCY 


•••«  ••t  Ifiilsi  to  nrjjwiny  sort,  print  r sport 

hsr*  •••*• 


STORl  '  *  TO  w«lt_oubot 

I  23,0  SAY  'Proas  any  kay  to  contlnua...'  OIT 
walt_aubst 

HAD 

SIT  CONTIRM  OH 

CASl  aalactniM  •  2 
*  DO  Clip  loaiPMEMT 


*  Call  Sorting  pro^ran,  sort  by  priority  or  coat  * 
DO  1M3_2_1 

aaaaa  fslat  CBtf  Iqaipaont  roport  boro  ••••• 


8BT  COMrZBM  OFF 
STORB  '  '  TO  tfalt_aubst 

•  23,0  SAY  'Proas  any  kay  to  contlnua...'  OCT 
volt  aubat 

~  MLAD 

SIT  COMFIRM  OH 

CASl  aalaetnun  •  3 
*  DO  BY  8TAT0S  CODE 


Bot  ladox  to  otatua  eodo  sort,  print  roport 


SIT  COHFIRM  OFF 
STORE  '  '  TO  trolt_a\ibBt 

9  23,0  SAY  'Proas  any  kay  to  contlnua...'  GET 
oalt^aubat 

READ 

SIT  COHFIRM  OH 

IMDCASI 


BBT  COHFIRM  OFF 

8TORB  '  '  TO  walt_aubst 

9  23,0  SAY  'Proas  any  kay  to  contlnua...'  OIT 
valt^aubat 

READ 

SIT  CONFIRM  OH 

CASl  aoloetnun  ■  3 

*  DO  CAPR  IQOIPMIHr 

*  Call  Sorting  progran,  sort  by  priority  or  coat  * 
DO  IM3_2_1 

aaaaa  print  CAPR  BqnipMSit  roport  boro 

SIT  CONFIRM  OFF 

STORE  '  '  TO  walt_aubat 

9  23,0  SAY  'Praaa  any  kay  to  oontlnua...'  GET 
wait  aubat 


BNDOO  T 
RETTJRR 

*  COP:  BMIND3_l.PRO 
*3 


*  Progran. . : 

BODB^I.PRO 

*  Author...:  JOAH  EIIMBRHAH  (  ELBERT  SIAN 

*  Data . i  02/17/89 

*  Notica...:  copyright  (c)  1989,  aoAH  eximerman  4  ELBERT 
SEAN,  All  Rights 

*  Raaarvad 
SIT  TALK  OFF 
SET  BILL  OFF 
SIT  STATOS  OFF 
SIT  BSCAPC  OFF 
SET  CONFIRM  OH 
OSE  EQUIP 

DO  HHILB  .T. 

*  ^'-Display  nonu  options,  cantarad  on  tha  acraan. 

*  draw  awftu  border  and  print  baading 
CLEAR 

9  2,  0  TO  14,79  DOUBLE 

9  3,15  SAY  C^ROCUREMENT  TYPE  RCPOR 
T  SJ 

9  4,1  TO  4,76  DOUBLE 

*  — <llaplay  datail  linos 

9  7,32  SAY  [1.  HBDCASC  BQUIPMEHT] 

9  8,32  SAY  (2.  CBIP  BQUIPMBHT] 

9  9,32  SAY  C3.  CAPR  BQUIPMEHTI 

9  10,32  SAY  {4.  OTBBR] 

9  12,  32  SAY  '0.  BXXT' 

STORE  0  TO  aoloetnun 
9  14,33  SAY  ”  aoloct 

9  14,42  OIT  aoloetnun  PICTURE  "9"  RANGE  0,4 
READ 

DO  CASE 

CASl  aoloetnun  -  0 
RETURN 

CASl  aoloetnun  *  1 
*  DO  MBDCASB  BQUIPMINT 


*  Call  Sorting  program,  sort  by  priority  or  coat  * 
DO  IM3_2_1 

*****  Print  IBDCABB  Bguipnont  roport  boro  «**•• 

SIT  CONFIRM  OFF 


RIAD 

SIT  CONFIRM  ON 

CASl  aoloetnun  >  4 
*  DO  OTBBR 


*  Coll  Sorting  program,  sort  by  priority  or  coat  • 
DO  IM3_2^1 

aaaa*  print  OTEIR  IgnipOMBt  roport  boro  ***** 

SIT  CONFIRM  OFF 
STORE  '  '  TO  woit^aubat 

9  23,0  SAY  'Pro*a~’ony  koy  to  contlnuo...'  GET 
walt^aubat 

RIAD 

SIT  CONFIRM  ON 

BNDCASE 

INDDO  T 
RETURN 

•  EOF:  BHBHU3_2.PR6 


*  Program. . : 

BI3_2_1  .PR0 

*  Author...:  JOAN  £I»BSRMAN  4  ILBERT  SBAN 

*  Data . :  02/17/89 

*  Notica...:  Copyright  (c)  1999.  JOAN  2I>MtRMAN  «  ILBIRT 
SIAN,  All  Rights  Raaarvad 

SET  TALK  OFF 
SET  BELL  OFF 
SET  STATUS  OFF 
SET  ESCAPE  OFF 
SET  CONFIRM  OH 

DO  NI7LE  .T. 

*  - Display  nanu  options,  contorad  on  tha  scraan. 

*  draw  manu  botdar  ani  print  haading 
CLEAR 

9  2,  0  TO  12,79  DOUBLE 

9  3,15  SAY  [C  BOOSE  DESIRED  SORT  OPT 
ION) 

9  4, 1  TO  4, 78  DOUBLE 

*  ---display  datail  llnas 

9  7,33  SAY  [1.  SORT  BY  PRIORITY] 

9  8,33  SAY  [2.  SORT  BY  COST] 

9  10,  33  SAY  '0.  EXIT' 

STORE  0  TO  aalaetnum 

9  22,33  SAY  "  aalact 
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«  12,42  QBT  Mlactixun  PICTtTRK  "9”  RAHOB  0,2 
READ 

DO  CASB 

CASE  ••l«etnua  •  0 
RBTDRlf 

CABB  ••l«otAuik  •  1 
«  DO  SORT  BY  PRIORITY 

••*•••  ••t  ImdwMa  Imt*  to  cort  by  priority 


SBT  COHTIRM  OPP 
STORE  '  '  TO  wolt^subat 

t  23,0  SAY  'Proa*  any  toy  to  contlnuo. . . *  OBT 
wolt_aubat 

READ 

RETURH 

CASE  aoloctnuia  ■  2 
*  DO  SORT  BY  COST 


Bot  iadoMO  horo  to  oort  by  eo«t 


SBT  C(WP1RM  orr 

STORE  '  '  TO  wolt_aubat 

t  23,0  SAY  'Proaa  any  kay  to  contlnua...'  OBT 
walt^aubat 

READ 

RETORN 

BMDCASB 

BMDDO  T 
RBTORN 

*  BOP I  BM3_2_l.PRO 
'^Z 


*  Proqran. . t 

*  AuttkOr...)  JOAH  EIM<BRMAN  «  BtBBRT  SRAM 

*  Data . I  02/17/89 

*  Kotlca...]  Copyright  (el  1989,  JOAK  SIM^ERMAK  4  BtBBRT 
SBAB,  All  Rl9hta  Roaarvad 

SBT  TALK  OPP 
SBT  BELL  OPP 
SET  STATUS  OPP 
SBT  ESCAPE  OPP 
SBT  COlfPIRM  ON 
USB  BQUIP 

•««**  29t  coat  aort,  hi^haat  to  lowaat 
DO  NBXLB  .T. 

•  — -Dlaplay  manu  optlona,  eantarad  on  tba  acraan. 

•  draw  manu  bordar  and  print  baadln9 
CLEAR 

•  2,  0  TO  14,79  DOUBLE 

•  3,  17  SAY  (PRIORITY  ffORRSBECT  FORM 

SJ 

i  4,1  TO  4,78  DOUBLE 

•  - dlaplay  datail  llnaa 

f  7,29  SAY  [1.  MEDCASE  PRIORITY  FORM] 
f  6,29  SAY  (2.  CBEP  PRIORITY  FORM] 

I  9,29  SAY  (3.  CAPR  PRIORITY  FORM] 
i  10,29  SAY  [4.  OTBBR  PRIORITY  FORM] 
i  12,  29  SAY  '0.  EXIT' 

STORE  0  TO  aalactnun 
t  14,33  SAY  ”  aalact 

I  14,42  GET  aaXaetnum  PICTURB  ”9"  RANGE  0,4 
READ 

DO  CASE 

CASB  aalaetnum  *  0 
RETURN 

CASB  aalaetnum  ■  1 

•  DO  HBDCASB  PRIORITY  FORM 

•  BBPOKT  rOBM  III3_3  POP  RSQTYPEi^BDC  TO  PRINT 


SBT  CONFIRM  OPP 

STORB  '  '  TO  wait_aub#t 

%  23,0  SAY  'Prasa  any  kay  to  contlnua..,'  GET 
walt^aubat 

READ 


SBT  CONFIRM  ON 

CASB  aalaetnum  «  2 

•  DO  CBtr  PRIORITY  FORM 

•  RSPOSIT  POMI  BI3_9  AU.  POR  RBOnPEaCBBP  TO  PRINT 


SBT  CONFIRM  OPP 
STORB  '  '  TO  walt_aubat 

t  23,0  SAY  'Praaa  any  kay  to  continua...'  OBT 
walt_^aubat 

READ 

SBT  CONFIRM  OH 

CASB  aalaetniaa  ■  3 

*  DO  CAPR  PRIORITY  FORM 

*  R»CRT  PCNM  mOJi  ALL  POR  RSOTYTEiCAPR  TO  PRINT 

SET  CONFIRM  OFF 
STORB  '  '  TO  wait_aubat 

I  23,0  SAY  'Praaa  any  kay  to  eontlnua...'  GET 
walt^aubat 

READ 

SET  COHPIRM  OH 

CASB  aalaetnum  ■  4 

*  DO  OTBBR  PRIORITY  FORM 

*  REPORT  FORM  M3_3  ALL  POR  RBOTYBBaOTEB  TO  PRINT 

SBT  CONFIRM  OFF 
STORE  '  '  TO  wmlt^aubat 

I  23,0  SAY  'Praaa  any  kay  to  eontlnua...'  OBT 
walt^aubat 

READ 

SBT  CONFIRM  OH 

BMDCASB 

BMDDO  T 
RETURN 

*  BOFt  BMBNU1_3.PRO 
''Z 


*  Program. . t 

MUm3_4.PR0 

•  Author... t  JOAN  BXPKERMAN  4  ELBERT  SBAN 

•  Data . .  02/17/69 

*  Notlca...t  Copyrl9ht  (e)  1989,  JCkAN  IIMRMRN  4  ELBERT 
SEAN,  All  Ri^bta  Raaarvad 

SBT  TALK  OFF 
SBT  BELL  OFF 
SBT  STATUS  OFF 
SBT  ESCAPE  OFF 
SBT  CONFIRM  OH 
USB  BOSXST 

DO  NBILB  .T. 

«  - Dlaplay  manu  optlona,  eantarad  on  tba  acraan. 

*  draw  manu  bordar  and  print  baadlng 
CLEAR 

f  2,  0  TO  12, 79  DOUBLE 

I  3,23  SAY  (HISTORICAL  REPORTS] 
f  4,1  TO  4,78  DOUBLE 

*  — -dlaplay  datail  llnaa 

t  7,27  SAY  (I.  PRINT  HISTORICAL  DATA  REPORTS] 
t  8,27  SAY  (2.  PRINT  HISTORICAL  8UI«4ARY) 
f  10,  27  SAY  '0.  EXIT' 

STORE  0  TO  aalaetnum 
9  12,33  SAY  ”  aalact  " 

9  12,42  GET  aalaetnum  PICTURE  "9"  RANGE  0,2 
READ 

DO  CASE 

CASB  ralactnum  ■  0 
RETURN 

CASB  aalaetnum  •  1 
*  DO  PRINT  ALL  BXSTORICAL  DATA 
DO  EM3_4_1 

SBT  CONFIRM  OFF 
STORE  ’  '  TO  walt_aubat 

9  23,0  SAY  'Praaa  any  kay  to  continue...'  GET 
walt__aubat 

READ 

SET  CONFIRM  ON 
CASB  aalaetnum  ■  2 
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*  DO  PKIMT  aiSTORlCAL  SDtMRRY 

*  TIE  STfTORICAL  EDIMRRY  ROOTTHl  TAKES  THE  HTSTOFICAL 

ri  t.t 

*  AMD  eCNPUnS  TBS  POLLOWINO  IMTOmATIOM 

*  TBS  TOTAl.  MCNBSK  OP  REQUESTS  »Y  TYPE 

*  TEE  AVERAGE  COST  PER  TYPE 

*  TBE  AVERAGE  TIME  TO  COMPLETE  TBE  ACTIOM  BASED 

OM  TBE 

*  DURATION  IMTORMATION  COMPUTED  UPON  ARCHIVING 

*  THE  MOMBER  OP  REQUESTS  BY  SECTION,  THEN  TYPE 

*  THE  AVERAGE  COST  BY  SECTION,  THEN  TYPE 

*  PUNT  mincmicKL  mamoact  rspont  km 

SET  CONFIRM  OFF 
STORE  '  '  TO  w«it_subst 

9  23,0  SAY  'Pr«s«  mny  k«y  to  eontinuo*..*  OIT 
WGit_SUt>St 

READ 

SET  CONFIRM  ON 

BMDCASE 

BMDDO  T 
RETURN 

•  EOF:  EMEMU3  4. PRO 


*  ProGYM. .  i 

■C3_4_l.PRfl 

*  Author...:  JOAN  ElftMERMAN  «  ELBERT  SHAN 

*  Dato . t  02/17/69 

*  Notlea...:  Copyright  (e)  1969,  JOAN  22»H4BRMAN  «  ELBERT 
SHAN,  All  Rights 

*  Rasarvad 
SET  TALK  OFF 
SET  BELL  OFF 
SET  STATUS  ^F 
SET  ESCAPE  <^F 
SET  CONFIRM  OM 

*  Oat  dasirad  aarllast  aonth  of  raport 
CLEAR 

M  DATE  •  • 

94,0  TO  6,79  DOUBLE 

9  7,10  SAY  *Eatar  tha  aarllast  Month  and  Yaar  for  hlstosieal 
raport : ” ; 

GET  M  DATE  PICTURE  "XX/XX" 

READ 

IF  MJDATE  •  "  - 

“loop 

BNDXF 

DO  HBILE  .r. 

«  »-Dlsplay  tMnu  options,  cantarad  on  tha  scraan. 

*  draw  aanu  bordar  and  print  haading 
CLEAR 

9  2,  0  TO  13.79  DOUBLE 

9  3, 23  SAY  [HISTORICAL  REPORTS] 

9  4,1  TO  4, 76  DOUBLE 

*  - display  datall  llnas 

9  7,33  SAY  [1.  BY  SECTION) 

9  6,33  SAY  [2.  BY  EQUIPMENT  TYPE] 

9  11,  33  SAY  '0.  EXIT' 

STORE  0  TO  salaetnum 
9  13,33  SAY  "  salaet 

9  13,42  GET  salactnun  PICTURE  "9"  RANGE  0,2 
READ 

DO  CASE 

CASE  salactnun  •  0 
RETURN 

CASE  salactnun  *  1 
•  DO  BY  SECTION 

*****  Sat  indaxas  hara  for  saetlons  ***** 


aa***  Print  Elotecleal  raport  by  Saetioa  hara  ••••* 

SET  CONFIRM  OFF 

STORE  '  '  TO  »alt_SUbst 

9  23,0  SAY  'Prass  any  kay  to  continua...'  GET 
wait_subst 

READ 

SET  CONFIRM  OH 

CASE  salactnun  •  2 
*  DO  BY  CATEGORY 


*****  Sat  Indaxas  hara  for  Equlpnant  typa  *•••• 

*****  Print  Blstariaal  r apart  by  Bgalpssant  Typa  bora 


SET  CONFIRM  OFF 
STORE  '  '  TO  walt__subst 

9  23,0  SAY  'Prass  any  kay  to  continua...'  GET 
wait_subst 

READ 

SET  CONFIRM  OM 

ENDCASE 

ENDDO  T 
RETURN 

*  EOF:  EM3_4  l.PRO 


*  Progran..: 

BBaU3_S.PRO 

*  Author...:  JOAN  2IIB4BRMAN  <  ELBERT  SHAN 

*  Data. . . . 02/17/69 

*  Notlea...:  Copyright  <c)  1969,  JOAN  EXM4ERNAN  C  ELBERT 
SHAN,  All  Rights  Rasarvad 

SET  TALK  OFF 
SET  BELL  OFF 
SET  STATUS  OFF 
SET  ESCAPE  OFF 
SET  CONFIRM  OM 

DO  NBILE  .T. 

*  —-Display  nanu  options,  cantarad  on  tha  scraan. 

*  draw  nanu  bordar  and  print  haading 
CLEAR 

92,  0  TO  12,79  DOUBLE 

9  3,14  SAY  [E^CPORT  FILES  TO  SPREADS 
fi  1  E  T) 

9  4,1  TO  4,78  DOUBLE 

*  -—display  datall  llnas 

9  7,26  SAY  [1.  EXPORT  CURRENT  DATABASE] 

9  6,26  SAY  [2.  EXPORT  BISTORZCAL  DATABASE) 

9  10,  26  SAY  '0.  EXIT' 

STORE  0  TO  sal%etti>» 

9  12,33  SAY  ”  salaet  * 

9  12,42  GET  salactnun  PICTURE  "9*  RANGE  0,2 
READ 

DO  CASE 

CASE  salactnun  •  0 
RETURN 

CASE  salactnun  •  1 
*  DO  EXPORT  CURRENT  DATABASE 

USE  EQUIP 

•*•••  Nrlta  CURMMT  DATABASB  axport  progran  bara 


CLOSE  ALL 

SET  CONFIRM  OFF 

STORE  '  '  TO  walt_SUbst 

9  23,0  SAY  'Prass  any  kay  to  continua...'  GET 
walt^subst 

READ 

SET  CONFIRM  OM 

CASE  salactnun  •  2 
*  DO  EXPORT  HISTORICAL  DATABASB 

USE  BQBIST 

•  ••**  Nrita  BltTOIIXCAL  DATABASB  aj^rt  progran 


CLOSE  ALL 

SET  CONFIRM  OFF 
STOPI  '  '  TO  wait_subst 

9  23,0  SAY  'Prass  any  kay  to  continua...'  GET 
wait  Bubst 

READ 

SET  CONFIRM  ON 

ENDCASE 

ENDDO  T 
RETURN 
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*  tort  tMiiioa  5. PRO 


•  Author...}  JOAM  hXIMRHRM  4  ELBERT  SHAN 

•  Dot* . }  02/16/$9 

*  Motieo...}  Copyright  (c)  1989,  JQRH  ZltMERHRH  4  ELBERT 
SIAM,  All  Rights  Rossrvsd 

*  Kotos. . . . i 


SET  TALK  orr 
SET  BELL  orr 
SET  STATUS  orr 
SET  ESCAPE  orr 

BBT  CONTIRM  OH 


*  -'-’‘Display  nonu  options,  eontorod  on  tho  scroon. 

*  draw  »onu  bordor  and  print  hoadlng 
CLEAR 

AM8NBR  •  "  " 

t  4,  0  TO  16,79  DOUBLE 

§  5,15  SAY  lARCBIVE  TO  HISTORICAL  P 
1  L  E) 

t  6,1  TO  6,78  DOUBLE 

9  8,15  SAY  "CAUTION:  All  fllos  with  a  roeolvod  status, 
RC,  will  bo" 

i  9,25  SAY  "raaovad  fron  tha  aqulpnant  listing" 
t  10,25  SAY  "to  tho  historical  £ila." 

I  14,25  SAY  "Do  you  wish  to  eontlnuo  tha  archive?  (Y/MJ"; 
OET  ANSNER  PICTURE  "lA" 

READ 

Zr  ANSNER  #  "Y" 

RETURN 

ELSE 

0  18,15  SAY  Program  to  Archive  Pllo 

•  TBS  PROORAH  SEARCHES  THE  ACTIVE  PILE  POR  STATUS 

CODES  «  RC 

•  IP  POUND  It  TRANSPERS  THE  NECESSARY  PIELDS  TO  THE 
HISTORICAL 

•  PILE  AND  eOKPUTES  THE  DURATION  IN  DAYS  BETNEEN  THE 
REQUEST 

•  DATE  AMD  CURRENT  SYSTEM  DATE.  THE  SYSTEM  DATE  IS 

ALSO  INSERTED 

•  INTO  THE  HISTORICAL  DATABASE  RECORD  ALON  NITH  THE 
COMPUTED 

•  DURATION. 

ENDir 

NAIT  "Press  any  key  to  continue  ..." 

SET  STATUS  CM 
SET  TALK  ON 
CLEAR  ALL 
RETURN 


RETURN 

*  BOP:  BMENU4.PR0 
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APPENDIX  X.  PERSONNEL  PROGRAMS 


TABLE  or  PROOMMB 

PMBNO.PRO 
PHBHOl . PRO 
PtOlfOZ .  PRO 
PMBIICrS .  PRO 
PMEN04.PRa 
PtaMU4_l .  PRO 
PMB!n74_2 .  PRO 
PMBIfD4_S,PR0 
PMEKD4_4 .  PRO 
PtONUS .  PRO 
PMBIIU6 .  PRO 


DXECLAXm 

The  purpose  of  this  programming  code  is  to 
facilitate  the  understanding  of  the 
requirements  presented  in  Chapter  5  of  this 
thesis,  rh«  nature  of  this  project  precludes 
it  actuai  inpiementation  in  DBASE  III+.  To 
fully  inplement  the  requirements  the  system 
designer  will  need  a  full  range  of  capabilities 
that  does  not  currentiy  exist  in  DBASE  IIJ+, 

DBASE  III*  served  as  the  modeling  tool  by 
Mhich  the  screens  were  generated  and  where 
necessaryf  specific  code  was  written  to 
illustrate  a  point.  The  actual  working  code 
merely  acts  as  a  shell  in  which  to  run  the 
menus.  A  close  analysis  of  the  program  code  can 
facilitate  implementation  in  a  more  suitable 
language,  i.e.,  PARADOX,  which  can  support  the 
graphics  and  high  level  relationships  involved 
in  the  various  databases .  Where  the  actual 
requirements  process  may  appear  to  be  unclear, 
comments  were  added  within  the  code  to  explain 
these  areas  to  the  designer. 


*  Pro9r«ii: 

PWEU.PRO 

*  Author.:  BLBBRT  T.  SHAN  «  JOAN  ZIMMRHAN 
«  Oat«. . . :  02/02/89 

*  Notleo.:  Copyright (e) 1989.  I.  T.  SHAN  «  JOAN  ZIMiERMAN, All 
Right*  R«*«rv«d  *  Not** . . . . iiteln  M*nu  for  tb«  P*r*onn«l 
Sy*t«iB 

SBT  TALK  orr 
SET  BELL  orr 

SET  ESCAPE  O^^ 

SET  COMriRM  ON 

DO  NHZLE  .T. 

*  DiaplNy  a«nu  option*.  c«nt*r«d  on  th«  *cr««n. 

*  draw  Mnu  berdor  and  print  baading 
CLEAR 

f  2.  0  TO  14. 79  DOOBLE 

t  3.15  SAY  [DEPARTMENT  OP  PAHILY  PPATTICC  PERSONNEL 
SYSTEM! 

9  4,1  TO  4,78  DOUBLE 

*  - display  datall  lino* 

*  7,22  SAY  [1.  Updata  Paraonnal  Liatlng] 
f  8,22  SAY  (2.  Updata  TDA  Listing] 

f  9,22  SAY  [3.  Quick  Updata  from  RZR  Raport] 
f  10,22  SAY  [4.  Updata  CME  Llsting/Budgat] 

9  11,22  SAY  [5.  Updata  Laava  and  Absanca  Listings] 

9  12,22  SAY  [6.  Print  Raport*] 

9  14,  22  SAY  (0.  EXIT] 
salaetnun  •  0 
9  16,33  SAY  "  salaet 

*  16,42  OET  salactnum  PICTURE  "9”  RANGE  0,6 
READ 


CASS  aalactaua  •  0 
CLEAR  ALL 
RETURN 

CASE  salactnua  •  1 

*  DO  Updata  Paraonnal  Listing 

DO  PHENUl 

SET  CONPIRM  OPT 
STORE  *  '  TO  valt__*iib*t 

9  23,0  SAY  'Pras*  any  kay  to  eontlnua...'  OET 
wait  subst 

READ 

SET  CONPIRM  ON 

CASE  salaetnun  -  2 

*  DO  Updata  IDA  Listing 

DO  PHENU2 

SET  CONFIRM  OPP 

STORE  '  '  TO  wait^subst 

9  23,0  SAY  'Prass  any  kay  to  eontlnua...'  OET 
wait  subst 

“  READ 

SBT  CONFIRM  ON 

CASS  salactnujB  •  3 

*  DO  Quick  Update  fron  RIR  Raport 

DO  PMBNU3 

SBT  CONFIRM  OFF 
STORE  '  '  TO  wait^BUbst 

9  23,0  SAY  'Pros*  any  kay  to  continue...'  OET 
wait  subst 

READ 

SET  CONFIRM  ON 

CASE  salaetnun  •  4 

*  DO  Updata  CME  Llsting/Budgat 

DO  PHBNU4 

SET  CONFIRM  OPP 

STORE  '  '  TO  walt_^subst 

9  23,0  SAY  'Press  any  kay  to  continue...'  OET 
walt^subst 

“*  READ 

SET  CONFIRM  ON 

CASE  salaetnun  •  5 

*  DO  Updata  Leave  and  Absanca  Listings 

DO  PMXNU5 

SET  CONFIRM  OPP 

STORE  '  '  TO  wait^subst 

9  23,0  SAY  'Press  any  kay  to  continue...'  OET 
w*lt__sub*t 

READ 

SBT  CONFIRM  ON 

CASE  salaetnun  •  6 

*  DO  Print  Reports 

DO  PHSNU6 

SET  CONPIPM  OPP 

STOH  ■  ■  I w«it_SUb*t 

9  23,0  SAY  'Press  any  kay  to  continue..-'  GET 
wait  subst 

"  READ 

SET  CONPIRM  ON 

ENDCASB 

ENDDO  T 
RETURN 

*  EOF:  PMENU.PRQ 

’'Z 


DO  CASE 
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PRZ8S 


•  12,0  TO  14,79  DOUBLE 

I  13,5  SAY  ”TDA  POSITION  NOT  AtTTHORXEKD, 


*  Prograat 

faomi.Bito 

*  Author. I  BLBBRT  T.  SIAN  ft  JOAN  EIlftSRMAM 

*  Dot*. . . t  02/02/89 

*  llotloo.  iCopyrlght  (e)  1969,  B.  T.  SHAM  ft  JOAN  ZIMMERMAN, 

All  Rights  Rosorvod 

*  Not**. . . . lUPOATB  PBRSOHNBL  LZSTINQ 
SET  TALK  orr 

SET  BELL  orr 
SET  ESCAPE  orr 
SET  COHriRM  ON 
SELECT  A 

USE  TDA  INDEX  TDA 

SELECT  8 

USE  PERSON  INDEX  p  TDA 
SELECT  A  ~ 

JOIN  NZTH  B  TO  TEMP  rOR  TDA_PARA-b->TDA  PARA  .AMD. 

TDA  LZME«b->TDA_LZNE  .AND.  TDA_POSN-B->TDA_POSN 
CLOSE  st.T. 

DO  MHILE  .T. 

*  --.-Display  nanu  options,  eantarad  on  tha  seraan. 

*  draw  Manu  bordar  and  print  haading 
CLEAR 

•  2,  0  TO  14,79  DOUBLE 

i  3,17  HAY  [UPDATE  PERSONNEL  LISTIN 
OJ 

•  4,1  TO  4,78  DOUBLE 

*  — -display  datall  Unas 

•  7,30  SAY  [1.  ADD  DEPARTMENT  PERSONNEL] 

6  8,30  SAY  [2.  CHANOE  INTORMATION  ON  A  PERSON] 

8  9,30  SAY  [3.  DELETE  PERSON  PROM  LISTING] 
t  10,30  SAY  [4.  REVIIM  ALL  OEPAFIMENT  PERSONNEL 
INTORMATION] 

t  12,  30  SAY  '0.  EXIT' 

STORE  0  TO  salactnum 
§  14,33  SAY  ”  salact 

t  14,42  GET  salactnum  PICTURE  *’9'’  RANGE  0,4 

READ 

DO  CASE 

CASE  salactnum  ■  0 
CLEAR  ALL 
RETURN 

CASE  salactnum  •  1 
•  DO  ADD  INTORMATION 
Adding  •  .T. 

DO  MBILE  Adding 
CLEAR 

M_TDAPARA  •  0 

m'tdaline  •  0 

M__TDAPOSN  •  0 
M_COda  •  SPACE (S) 

8  6,0  TO  10,79  DOUBLE 

8  7,10  HAY  "ENTER  THE  ID  CODE  OF  THE  PERSON  YOU 
NISH  TO  ADD!"  GET  M_C0DB  PICTURE  "19999" 

8  8,10  SAY  "or  Prass  Raturn  to  QUIT" 

READ 

ir  M_COOE  ■  "  " 

Adding  ■  .r. 

LOOP 

ENDir 

USE  PERSON 
00  TOP 

LOCATE  rOR  IDCODE*m_coda 
ir  POUND  <) 

CLEAR 

MESSAGE  -  "ID  CODE  REQUESTED  IS  ALREADY  USED 
BY  THE  PERSON  SHOWN  BELOW  1" 

SET  rORMAT  TO  COttFlMi 
READ 

CLOSE  FORMAT 
LOOP 
ELSE 

TRY  -  .T. 

DO  WHILE  TRY 
M^TDAPARA  •  0 
CLEAR 

SET  rORMAT  TO  TDAIKPUT 
READ 

CLOSE  FORMAT 
USE  TDA 
GO  TOP 

LOCATE  FOR  TDA_PARA*M  TDAPARA  .AlC. 
TDA_HWE»M_TDAL1WE  .  AND  T TDA_POSN-M  TDAPOSN 
ir  POUND  <) 

SET  FORMAT  TO  POSITION 

READ 

CLOSE  FORMAT 

ELSE 


return  to  try  again. . 

WAIT  “  " 

LOOP 

BNDIF 

USE  PERSON 
00  TOP 

LOCATE  FOR  IDA  PARA"M  TDAPARA  .AND. 
TDA_LINX«M_TDALZNB  .AMD.  TDA_POSN«M  n>APOSN 
“  XF  FOUND  O  *"  ~ 

CLEAR 

SET  FORMAT  TO  OCCUPIED 

READ 

CLOSE  FORMAT 
8  19,0 

SET  FORMAT  TO  CHOICE 

READ 

DO  CASE 

CASE  ANSWER'l 

REPLACE  TDA^POSN  WITH  99 
SIT  FORMAT  TO  ftRBOH 
APPEND  BLANK 

REPLACE  IDCODB  WITH  M_CODB, ; 

TDA_PARA  WITH  M_TDAPARA, 

TDA_LINB  WITH  M_TDALTNE, 

TDA  POSH  WITH  M_TDAPOSN 

READ 

CLOSE  FORMAT 
TRY  -  .r. 

LOOP 

CASE  AN5WBR»2 

SET  FORMAT  TO  PERSON 
APPEND  BLANK 

REPLACE  XDCODE  WITH  M_CODE, ; 

TDA_PARA  WITH  M_TDAPARA, 

TDA^LINE  WITH  M^TDALINE, 

TDA  POSH  WITH  99 

READ 

CLOSE  FORMAT 
TRY  -  .F. 

LOOP 

CASE  AN8NER»3 

LOOP 

ENDCA8E 

ELSE 

SET  FORMAT  TO  PERSON 
APPEND  BLANK 

REPLACE  IDCODE  WITH  M  CODE, ; 

IDA  PARA  WITH'm  TDAPARA, 

tda'lznb  with  h'tdaline,  ; 

TDA_POSN  WITH  M[_TDAPOSH 

READ 

CLOSE  FORMAT 
TRY  •  .F. 

ENDIF 

EKDDO 

ENDIF 

YESHO  •  «  - 
8  6,0  TO  8,79  DOUBLE 

8  7,15  SAY  "DO  YOU  NISH  TO  INTER  SOCIAL  ROSTER 

INFORMATICM"  GET  YBSNO  PICTURE 

READ 

IF  YESNO  ■  "Y" 

*  SET  rORMhT  TO  PRIVATE 

*  APPEND  BLANK 

*  REPLACE  XDCODE  MITE  M_ZDCODB 

*  CLOSE  FORMAT 
"ENDIF 

"ENDDO  (ADDING) 

SET  CONFIRM  OFF 
STORE  '  '  TO  walt___aub»t 

I  23,0  SAY  'Praas  any  kay  to  contlnua...'  GET 
walt_aubat 

READ 

SET  CCWIFXRM  ON 

CASE  aalactnun  ■  2 
*  DO  CHANGE  INFORMATION 

*  SEEK  H  CODE 

"  XF  BLANK,  EXIT 

*  IF  FOUND  0 

*  SET  FORMAT  TO  PERSON 

*  CHECK  TO  INSURE  POSITION  IS  NOT  OCCUPIED  BY 

SOMEONE  *  XF  OCCUPIED 
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•  SIT  rORMKT  TO  CHOICE 

•  OIT  CHOXCI  AND  EXECUTE  PER  ADDING 
IMSTROCTICHS 

•  EMDir 

•ELSE  NOT  roUMD) 

•  MOTirY  USER  ID  NOT  fOUND,  GIVE  OPTION  TO  SEARCH 

•Y  LAST  NAME 

•  SEEK  LAST  NAME 

•  DISPLAY  ALL  NITH  THIS  LAST  NAME,  FIRST  NAME  AMD 

ID  COOS 

•  GIVE  USER  OPTION  TO  CHOSE  WHICH  RECORD  NUMBER 

•  USER  PICKS  RECORD  MDMBER 

•  GOTO  RECORD  SELECTED 

•  SET  FORMAT  TO  PERSON 

•  CHECK  TO  INSURE  POSITION  18  NOT  OCCUPIED  BY 

SOMEONE  •  IF  OCCUPIED 

•  SET  FORMAT  TO  CHOICE 

•  GET  CHOICE  AMD  EXECUTE  PER  ADDING 

INSTRUCTIONS 

•  EMDIF 
CLEAR 

•  €,0  TO  S,79  DOUBLE 

9  7,19  SAY  ”DO  YOU  NISH  TO  CHANGE  SOCIAL  ROSTER 
INFORMATION"  GET  YE3N0  PICTURE  "1" 

READ 

IF  YESNO  -  "Y" 

•USE  PRIVATE  INDEX  IDCODI 
•LOCATE  FOR  IDCODB^_IDCODS 
•IF  POUMDO  DO  FOLLOWING 

•  SET  FORMAT  TO  PRIVATE 

•  APPEND  BLANK 

•  REPLACE  IDCODI  WITH  M_IDCODB 

•  CLOSE  FORIAT 
•EMDIF 

•IF  .NOT.  FOUND  0  CilDCOOE  NOT  IN  PRIVATE  FILE 

•  WAIT  "ADDING  A  NEW  RECORD,  IDCODI  MOT 
FOUND.. PRESS  ; 

•RETURN  TO  CONTINUE..." 

•  SET  FORMAT  TO  PRIVATE 

•  APPEND  BLANK 

•  REPLACE  IDCOOE  WITH  M_XDCODE 

•  CLOSE  FORMAT 
•INDIF 

•EMDIF 

SIT  CONFIRM  ON 

CASS  s«l«etnun  •  3 
•  DO  REMOVE  INFORMATION 

9  TO  10,79  DOUBLE 

9  7,10  SAY  "INTER  THE  ID  CODE  OF  THE  PERSON  YOU 
WISH  TO  REMOVE:"  GET  M^CODE  PICTURE  "19999" 

9  S,10  SAY  "or  Proas  Roturn  to  QUIT" 

READ 

•SISK  M_CODE 
•IF  BLANK,  EXIT 

•IF  FOUNDS 

•MESSAGE  •  "  IS  THIS  THE  PERSON  YOU  WANT  TO  DELETE? 

(t/N)- 

•  SET  FORMAT  TO  CONFIRM 

•  READ  ANSWER 

•  IF  ANSWER  IS  NO  "N" 

•  LOOP  TO  TRY  ANOTHER  PERSON  CODE 

•  EMDIF 

•  IF  ANSWER  IS  YES  "Y" 

•  ASK  "ARE  YOU  SURE  (Y/N) " 

•  IF  SURE  IS  YES  "Y" 

•  LOCATE  AND  DELETE  (IN  PERSON) 

•  USE  ABSENSE 

•  LOCATE  AND  DELETE 

•  IF  NOT  FOUICO  CONTINUE 

•  USE  CMEREQ 

•  LOCATE  AND  DELETE 

•  IF  MOT  FOUmO  CONTINUE 

•  USB  PRIVATE 

•  LOCATE  AND  DELETE 

•  IF  NOT  FOUMDO  CONTINUE 

•  ELSE  (ANSWER  IS  NO  "N”) 

•  CLEAR 

•  99,  0 

•  WAIT 

•  ENDXF 

•ELSE  (l.«.  NOT  FOUND) 

•  NOTIFY  USER  ID  WOT  FOUND,  GIVE  OPTION  TO  SEARCH 

BY  LAST  HAMS 

•  IF  CHOICE  IS  TO  SEEK  BY  LAST  NAME 

•  SEEK  LAST  NAME 

•  DISPLAY  ALL  WITH  THIS  LAST  NAME 

•  GIVE  USER  OPTION  TO  CHOSE  WHICH  RECORD 

NUMBER 

•  USER  PICKS  RECORD  NUMBER 

•  GOTO  RECORD  SELECTED 

•  DISPLAY  LAST  NAME,  FIRST  NAME,  Ml  and  PANK 

•  ASK  "IS  THIS  THE  PERSON  YOU  WISH  TO  DELETE? 

(Y/N)  " 


•  READ  ANSWER 

•  IF  ANSWER  IS  NO  "N” 

•  LOOP  TO  TRY  ANOTHER  PERSON  CODE 

•  ENDXF 

•  Xr  ANSWER  IS  YES  "Y" 

•  STORE  IDCOOE  TO  M_IDCODE  4IDCODE  OF  CURR 

PERSON 

•  ASK  "ARE  YOU  SURE  (Y/N) " 

•  IF  SURE  IS  YES  "Y" 

•  LOCATE  M_XDCODE  AND  DELETE  (IN 

PERSON) 

•  USB  ABSENSE 

•  LOCATE  AMD  DELETE 

•  IF  NOT  FOO»()  CONTINUE 

•  USE  CMEREQ 

•  LOCATE  M  IDCODI  AMD  DELETE 

•  IF  NOT  FOU»()  CONTINUE 

•  USB  PRIVATE 

•  LOCATE  M  IDCM>B  AMD  DELETE 

•  IF  NOT  FOUmO  CONTINUE 

•  ELSE  (ANSWER  IS  NO  "M") 

•  CLEAR 

•  95,0 

•  WAIT 

•  EMDIF 

•  EMDIF 

•  IF  CHOICE  IS  ROT  TO  SEARCH  FOR  LAST  NAME 

•  LOOP  TO  BBOIMNING 

•  BNDIF 
•EMDIF 

9  e,0  TO  5,79  DOUBLE 

9  7,15  SAY  "DO  YOU  NISH  TO  CHANGE  SOCIAL  ROSTER 
INFORMATION"  GET  YESNO  PICTURE  "I" 

READ 

•IF  YESNO  •  "Y" 

•USE  PRIVATE  INDEX  IDCODE 
•LOCATE  FOR  IDCODE-H  IDCODE 
•IF  FOUND ()  DO  FOLLOWING 

•SET  FORMAT  TO  DELPHI VATE 
•ASK  "ARE  YOU  SURE  (Y/N)  " 

•IF  SORE  IS  YES  "Y" 

•  DELETE 

•ELSE  (ANSWER  IS  NO  "N") 

•  CLEAR 

•  95,0 

•  WAIT 
•EMDIF 

•EMDIF 

•IF  .NOT.  FOUND  0  44IDCODE  MOT  IN  PRIVATE  FILE 

•  WAIT  "IDCODE  NOT  FOUND. .PRESS  RETURN  TO 

CONTINUE. .." 

•EMDIF 

* 

SET  TALK  ON 
CLEAR 

9  2,0  HAY  '  ' 

7  'PACKING  DATABASE  TO  REMOVE  RECORDS  HARKED  FOR 
DELETION' 

•RACK  ALL  DATABASES  USED 

(FERSON,CI>aREQ,  ABSENCE,  PRIVATE)  SET  TALK  OFF 

SET  CONFIRM  OFF 
STORE  '  '  TO  WAlt^aubat 

9  23,0  SAY  'Frwaa  any  k«y  to  contlnu*...'  GET 
wait_»ubat 

READ 

SET  CONFIRM  ON 
CASE  aoloctnum  ■  4 

•  DO  REVIEW  INFORMATION  440NLY  PERSON  FILE 
BROWSE  NOAPPBND  WOMENU 

SET  CONFIRM  OFF 
STORE  '  '  TO  w«it_sul>at 

9  23,0  SAY  ' Froas  any  kRy  to  contlnua...'  GET 
v«lt_aubat 

READ 

SET  CONFIRM  ON 

ENDCASE 

ENDDO  T 
RETURN 

•  rrwNni.pRO 

'Z 


•  ProQram. . i 

PMBHUE.PKO 

•  Author...:  ELBERT  T.  SHAW  4  JOAN  ZIMMERMAN 

•  D«tR . :  02/02/59 

•  HotlCR.  :Copyrl9ht  (c)  1989,  ELBERT  T.  SHAW  4  JOAN  ZIMQtRMUt, 
All  Rights  RRBRxrvRd 

•  Not*#. . . .:UFDATE  TDA  LIST 
SET  TALK  OFF 

SET  BELL  OFF 
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«iT  iscApi  orr 

•tT  COlirXMi  ON 

OffI  TDA 
DO  miLI  .T. 

•  •>— Dl«pl«y  Mnu  options,  contorod  on  th*  ser««n. 

•  draw  Mnu  bordor  and  print  hsadinq 
CLEAR 

9  2,  0  ro  14,  79  2>ODELE 

•  3,23  EAY  (UPDATE  TDA  LISTZMO} 
f  4,1  TO  4,78  DOUELI 

•  — •display  datail  linas 

•  7,30  SAY  (1.  ADD  A  TDA  POSITION] 

t  8,30  lAY  (2.  CHANGE  A  TDA  POSITION'S  INrORMATIOK] 

I  9,30  SAY  [3.  REHOVE  A  TDA  POSITION] 
f  10,30  SAY  (4.  RSVIBN  ALL  TDA  POSITIONS] 

•  12,  30  SAY  '0.  EXIT* 

STORE  O  TO  salactnus 

t  14.33  SAY  "  salaet 

•  14,42  GST  salaetnum  PICTURE  "9"  RANGE  0,4 

READ 
DO  CASE 

CASE  salaetnuB  •  0 
CLEAR  ALL 
RETURN 

CASE  salaetnum  •  2 

*  DO  ADD  XNPMdlATXON 

*  ALLOWS  YOU  TO  ADO  A  NEK  TDA  POSITION  TO  TRE  MASTER 

LIST 

TRYING  •  .T. 

DO  WHILE  TRYING 

SET  FORMAT  TO  TDAIHPUT 
READ 

CLOSE  FORMAT 
USE  TDA 
GO  TOP 

LOCATE  FOR  1DA_PARA-M_T0APARA  .AND. 

TDA  LINE«M_TDALINE  .AND.  TDA_POSN-M  TDAPOSN 
IF  FOUND  0 
CLEAR 

SET  FORMAT  TO  OCCUPIED 

READ 

CLOSE  FORMAT 

ELSE 

9  12,0  TO  14,79  DOUBLE 

9  13,5  SAY  "IDA  POSITION  NOT  IN  CURRENT  FILE, 

PRESS  ; 

RETURN  TO  ADD  IT. . 

WAIT  "  - 
CLEAR 

M  AUTB  •  SPACE (1) 

4'‘4,0  TO  8,79 

9  7,15  SAY  *ZS  THIS  AN  AUTHORISED  POSITION? 

(Y/N)"; 

GET  M  AUTH  PICTURE  " I " 

READ 

SET  FORMAT  TO  TDA 
APPEND  BLANK 
IF  M_AUTH  •  "Y" 

REPLACE  AUTB  WITB  1 
ELSE 

REPLACE  AUTN  WITH  0 
ENDIF 

REPLACE  TDA_PARA  WITH  M  TDAPARA,  ; 

TDA_LINE  WITH  M*TDALINE,  ; 

TOA_POSN  WITH  M_TDAPOSH 

READ 

CLOSE  FORMAT 
ENDIF 
ENDDO 

SET  c^vriRH  orr 

STORE  '  '  TO  walt^aubat 

I  23,0  SAY  'Praaa  any  kay  to  continua...'  GET 
walt^Bubat 

READ 

SET  CONFIRM  ON 

CASE  aalaetnuiB  •  2 

*  DO  CHANGE  INTORMATION 

*  ALLOWS  YOU  THE  CAPABILITY  TO  CHANGE  A  TDA 

POSITION'S  INFO 

TRYING  -  .T. 

DO  WHILE  TRYING 

SET  FORMAT  TO  TDAINPUT 
READ 
USE  TDA 
GO  TOP 

LOCATE  FOR  TOA  PARA-M  TDAPARA  .AND. 
TDA_LIWE-M_TDALIKE  .AND.  TDA_POSN-M_TOAPOSN 

IF  FOUND O 
CLEAR 

ir  AUTB  •  0 

t  6,0  TO  0,7  9 


9  7,15  SAY  "DO  YOU  WANT  TO  CHANGE  THIS  TO 
AM  AUTHORIEED  POSITION?  (Y/M)  GET  M_AUTH  PICTURE  "J" 

READ 

IP  M  AUTH  •  "Y" 

RCPIACE  AtriH  WITH  I 
ENDIF 

SET  FORMAT  TO  TDA 

READ  «  CANNOT  CHANGE  THE  TDA  POSITION 
CLOSE  FORMAT 

ELSE  44  IF  AUTH  «  0 

9  6,0  TO  8,79 

8  7,15  SAY  "DO  YOU  WANT  TO  CHANGE  THIS  TO 
AN  UMAUTBORIEED  POSITION?  <Y/N) "  GET  M_AUTB  PICTURE  ”1” 
READ 

IF  M  AUTH  -  "Y" 

REPLACE  AUTH  WITH  0 
BNDIF 

SET  FORMAT  TO  TDA 

READ  4  CANNOT  CHANGE  THE  TDA  POSITION 
CLOSE  FORMAT 

ELSE 

9  12,0  TO  14,79  DOUBLE 

8  13,5  SAY  "IDA  POSITION  NOT  IN  CURRENT  FILE, 

PRESS  ; 

RETURN  TO  TRY  AGAIN.  .  .  ” 

WAIT  •  " 

LOOP 

ENDIF 

ENDDO 

SET  CMiriRM  OFF 

STORE  '  '  TO  walt^aubat 

9  23,0  SAY  'Praaa  any  kay  to  contlnua...*  GET 
aalt^aubat 

READ 

SET  CONFIRM  ON 

CASE  aalactnuA  ■  3 

*  DO  REMOVE  INTORMATION 

*  ALLOWS  YOU  TO  DELETE  A  NO  LONGER  AUTHORIZED  TDA 
POSITION 

TRYING  -  .T. 

DO  WHILE  TRYING 

SIT  FORMAT  TO  TDAIHPUT 
READ 
USB  TDA 
GO  TOP 

LOCATE  FOR  IDA  PARA-M  TDAPARA  .AND. 

TDA  LXNI<44_TDALIHE  .AND.  TDA  POSM^_TDAPOSN 
IF  FOUND O 

YBSIIO  •  SPACE  a  ) 

CLEAR 

9  2,0 

?  "JOBTITLt  APC  CODE" 

?  JOBTITLE,APC 
9  6,0  TO  8,79  DOUBLE 

9  7,15  SAY  "IS  THIS  THE  TDA  POSITION  YOU  WANT 
TO  DELETE?  (Y/M] "  GET  Y18NO  PICTURE  "I" 

READ 

IF  YESNO  •  -Y" 

DELETE 
USB  PERSON 

INDEX  ON  TDA_PARA  .AND.  TDA_LXNB  .AND. 
TDA_POSN  TO  TEMP 

SET  INDEX  TO  TEMP 

LOCATE  POR  TDA_PARA>M  TDAPARA  .AND. 

TDA  LZN1"M_TDALIKB  .AMD.  TDA_P08N>tr.TDAP0SN 
IF  FOUND  0 

REPLACE  TDA_PARA  WITH  0,  ; 

TDA_LZNB  WITH  0,  ; 

TDA_POSN  WITH  0 

CLEAR 

9  6,0  TO  9,79  DOUBLE 

9  7,5  SAY  "FOUND  "♦RANX4^"  "♦LNAMt^"  WHO 
IS 

OCCUPYING  THE  DELETED  POSITION,  IDCODI 
X8"+STR(1DC0DE,5) 

9  8,5  SAY  "BE  SURE  YOU  UPDATE  TIIS 
PERSON'S  TDA  POSITION  WITH  A  VALID  TDA  POSITION!" 

9  12,0 

WAIT 

ENDIF 

BLSB  44  YESNO  "N" 

LOOP 

ENDIF 


ELSE  44POSZTION  HAS  NOT  FOUND 
9  12,0  TO  14,79  DOUBLE 

9  13,5  SAY  "TOA  POSITION  NOT  IN  CURRENT  FILE, 

PRESS  ; 

RETURN  TO  TRY  AGAIN.  .  .  " 

WAIT  "  " 

LOOP 

ENDIF 

ENDDO 
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SIT  IMDIX  TO 
IRXSI  TIMP.NDX 
SIT  TALK  OH 

CLIAit 

t  2,0  SAY  '  ' 

?  'PACKXHQ  DATABASE  TO  AEMOVI  RICORDS  MARKED  FOR 
DILITIOM' 

PACK 

SIT  TALK  orr 
SIT  coNrxRM  orr 

STOM  '  '  TO  wait^subst 

9  23,0  SAY  'PrRss  any  kay  to  eontlnua...'  OIT 
wait_attb«t 

READ 

SIT  CONTIRM  OH 

CASI  saXactnuM  •  4 
*  DO  RSVXIH  ZHTOWMATIOtt 

*  ALLOWS  YOU  TO  RtVXIN  TIE 

COMPLETE  PILE 

XMDIX  OH  TDA  PARA  .AMD.  1T>A  LINE  .AMD.  n»A_POSN  TO 
TEMP  “  " 

SIT  INDEX  TO  TEMP 
BROHSI  NOAPPEND  MQKEND 
BRASI  TIMP.NDX 
SIT  COHTXRM  OPF 
STORE  '  '  TO  walt__#ubat 

9  23,0  SAY  'Praaa  any  kay  to  continua...*  GET 
walt_aubat 

READ 

SET  COHTXRM  ON 

IMDCASI 

IMDDO  T 
RBTURN 

•  lOn  PMBMU2.PRO 
*2 


*  Pro^ran. . : 

nBHVS.PRO 


*  Author...!  ILBIRT  T.  SRAM  «  JOAN  ZIIMERMAM 

•  Data . I  02/02/S9 

*  Notleai  Copyright (e)  19e»,|LBBRT  T.  sham  4  JOAN  ZXM4ERMAN, 
All  Rights  Raaaxvad 

•  NOTES  !  QUICK  UPDATE  PROM  RIR  RXPORT 
SIT  TALK  orr 

SIT  BILL  orr 
SET  iscAPi  orr 
SIT  COHriRM  ON 
USE  PERSON 
DO  NBXLE  .T. 

«  —.Display  laanu  options,  cantarad  on  tha  scraan. 

*  draw  isanu  bordar  and  print  haadlng 
CLEAR 

9  2,  0  TO  12,79  DOUBLE 

9  3, 13  SAY  [QUICK  UPDATE  FROM  RIR  R 
E  P  O  R  TJ 

9  4, 1  TO  4, 78  DOUBLE 

*  - display  datail  linas 

9  7,23  SAY  [1.  Updata  Lossas] 

9  8,23  SAY  (2.  Updata  Changas  to  TDA  Positions] 

9  10,  23  SAY  '0.  EXIT' 

STORE  0  TO  salactnun 
9  12.33  SAY  "  salaet 

9  12.42  GET  salaetnum  PICTURE  "9"  RANGE  0.2 
READ 

DO  CASE 

CASE  salaetnum  ■  0 
CLEAR  ALL 
RETURN 

CASE  salaetnum  *  1 
*  DO  Updata  Lossas 

•DO  NBXLE  TRYING  4S  MASTER  LOOP  FOR  MULTIPLE 

IHTRIES 

M_UPDATETYPE  •  1 
9  6.0  TO  9,79  DOUBLE 

9  7,10  SAY  *BAS  TB18  PERSON  ACTUALLY  DEPARTED  OR  IS 
TRIS  AH  UPDATE  TO  A  PROJECTED  LOSS  DATE?  (ACTUALoO, 

UPDATI  DATI-D"  OIT  M_UPDAnTYPE  PICTURI  *9"  RANGE  0,1 
READ 

9  19,0  TO  19,79  DOUBLE 

9  16,10  SAY  "ENTER  THE  ID  CODE  OP  TBE  PERSON 
NHO"+irr (M_UPOATETYPE  •!,  "LOSS  DATE  NEEDS  CHANGING", 


"DEPARTED"! +*:"  GET  M  CODE  PICTURE  ^19999" 

9  17,10  SAY  "or  Trass  Raturn  to  QUIT" 

READ 

•USE  PERSON 
•tSEEr  }l_COf;E 
•ir  BLANK,  EXIT 
•IF  POUND () 

*  DISPLAY  LAST  NAME,  FIRST,  AND  RANK 

*  HESSAOE  •  "IS  THIS  TBS  PERSON  YOU  NTSB  TO 
MODIFY?  (Y/N) " 

*  SIT  FORMAT  TO  CONTIRM 

*  ir  ANSNXR  IS  NO  "N" 

*  LOOP  TO  TRY  ANOTBIR  PIRSON  CODE 

*  INDir 

*  Xr  ANSNIR  IS  YIS  "Y" 

*  ir  H_UPDATITYP1  IS  1  tCAPPIND  NIN  LOSS  DATE 

*  CLEAR 

*  9  6,0  TO  8,  79  DOUBLE 

*  9  7,15  SAY  "INTIR  NIN  LOSS  DATS: 
(>#4/DD/YY) 


OIT  M_LOSS  PICTURI  *99/99/99" 
READ  ” 

RIPLACI  ALOIS  NIT8  M  LOSS 
LOOP  TO  DO  ANOT8BR  PERSON 
ENDir 

ASK  -ARl  YOU  SURE  (Y/N)" 

If  SURE  IS  YES  "Y" 

LOCATE  AND  DELETE  (IN  PERSON) 

USE  ABSSNSt 
LOCATE  AMD  DELETE 
ir  MOT  FOUND ()  CONTINUE 
USE  CMBRIQ 
LOCATE  AMD  DELETE 
IF  NOT  rOUlCO  CONTINUE 
USB  PRIVATE 
LOCATE  AMD  DELETE 
IF  NOT  FOUND ()  CONTINUE 
ELSE  (ANSWER  IS  NO  "N") 

CLEAR 

95,0 

WAIT 

ENDXr 


•ELSE  (l.a.  HOT  FOUND) 

•  NOTIFY  USER  ID  NOT  FOUND,  GIVE  OPTION  TO  SEARCH 

BY  LAST  NAME 

•  IF  CaOXCB  IS  TO  SEEK  BY  LAST  NAME 

•  SEEK  LAST  lAMI 

•  DISPLAY  ALL  WITH  TBtS  LAST  NAME 

•  GIVI  USSR  OPTION  TO  CBOSS  NHICB  ID  CODE 

•  USER  PICKS  ID  CODS 

•  GOTO  ID  CODE  SELECTED 

•  DISPLAY  LAST  NAME,  FIRST  NAME,  MI  and  RANK 

•  KESSAGE«”IS  TBIS  TBE  PERSON  YOU  NISH  TO 
DELETE? (Y/N) 


PERSON) 


SET  FORMAT  TO  CONFIRM 
READ  ANSWER 
IF  ANSWER  IS  NO  *N" 

LOOP  TO  TRY  ANOTBIR  PERSON  CODE 
EHDir 

IF  ANSWER  18  YES  ”Y" 

STORE  IDCODE  TO  M_IDCODE 
ASK  "ARE  YOU  SURE  (Y/N) " 

IF  SURE  IS  YES  "Y" 

LOCATE  M_IDCODE  AND  DELETE  (IN 

USB  ABSBNSE 
LOCATE  AND  DELETE 
IF  NOT  FOUND ()  CONTINUE 
USE  CMIREQ 

LOCATE  M  IDCODE  AND  DELETE 
IF  NOT  rOUICO  CONTINUE 
USB  PRIVATE 

LOCATE  H_IDCODB  AND  DELETE 
IF  HOT  FOUND  0  CONTINUE 
ELSE  (ANSWER  IS  NO  "N") 

CLEAR 

99,0 

WAIT 

ENDXr 


ENDir 

IF  CHOICE  IS  NOT  TO  SEARCH  FOR  LAST  NAME 
LOOP  TO  BEGINNING 

ENDir 

ENDXF 

ENDDO 


SET  CONFIRM  OFF 

STORE  '  '  TO  walt_aub»t 

9  23,0  SAY  'Praia  any  kay  to  continua...'  GET 
wait^aubat 

READ 

SET  CONFIRM  ON 
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CASE  ••l«ctnun  •  2 

*  DO  D|>da*'#  Chanq««  to  TDA  Positions 
*D0  WIXLt  TRDI 

*ALLOIIS  YOU  TO  CHANGE  THE  TDA  POSITION  PROH  THE  RIF 
SET  FORMAT  TO  PERRIR  <4  scroan  of  fMisory  varlabia 
READ 

•IP  M_TDAPARA  •  0 

•  EXIT 
•EHDir 
•USE  PERSON 

•l^OCATE  FOR  TDA  PARA-M_TDAPARA  .AND. 

TDA_LIIfS-M  TDALINE  '  •.AND.  TDA  POSN«M  TDAPOSN 

•IF  FOUND  ()..  MEANS  TEAT  THE  mu  POsTtION  IS 
OCCUPIED,  GIVE  CHOICES  AS  LISTED  BELON 

•  STORE  IDCCDE  TO  OLDPERSON  44RBCORD  WHO  TBE 

PERSON  *  CLEAR 

•  I  7,0 

•  SET  FORMAT  TO  CHOICE 

•  READ 

•  DO  CASE 

•  CASE  ANSWER*! 

•  USE  TDA 

•  «4  LOOK  FOR  TBE  TDA  TO  MAKE  SURE  IT  IS 

O.R. 

•  LOCATE  FOR  TDA_PARA"M_TDAPARA  .AND. 
TDA_LINE*M_TDALINX  .AND.  TDA_P08N-M_TDAP0SN 

•  IF  FOUND O  44AUTBORI2ED  SLOT 

•  USE  PERSON 

•  LOCATE  FOR  IDCODE*M_IOCOOE  44  PERSON 

TO  CHANGE  POSN 

•  IF  .NOT.  FOUND  0 

•  CLEAR 

•  0  6,0  TO  0,79  DOUBLE 

•  0  7,!5  SAY  "IDCODE  DOES  NOT  EXIST, 

PRESS  RETURN  TO  TRY  AGAIN..* 

•  LOOP 

•  ENDIF 

•  REPLACE  TDA_PARA  WITH  M_TDAPARA,  ; 

•  TDA_LINE  WITH  M_TDALINE,  ; 

•  TDA_P0SN  WITH  H  TDAPOSN 

•  GO  TOP 

•  LOCATE  FOR  IDCODE-OLOPERSON 

•  REPLACE  TDA  POSN  WITH  99  44PUT  TBE 

OLDE  PERS^  IN  EXCESS  ~ 

•  ELSE 

•  0  6,0  TO  0,79  DOUBLE 

•  0  7,5  SAY  -TDA  POSITION  ENTERED  IS 

MOT  AN  AUTHORIIED  IDA  POSITION" 

•CHECK  INFORMATION  AMD  PRESS  RETURN  TO  TRY 

AGAIN. . . " 

•  WAIT  "  " 

•  LOOP 

•  ENDIF 

•  RBPLRCE  TDA_POSK  WITH  99 

•  TRY  ■  .r. 

•  LOOP 

«  CASE  ANSWER-2 

•  USE  TDA 

•  44  LOOK  FOR  TBE  TDA  TO  MAKE  SURE  XT  IS 

O.R. 

•  LOCATE  FOR  TDA__PARA>H_TDAPARA  .AND. 

TDA_LINE-M_TDALIME  .AND.  TDA_POSN-M  TDAPOSN 

•  IF  FOUND  0  4 4 AUTHORIZED  SLOT 

•  USE  PERSON 

•  LOCATE  FOR  IDCOOE-M_IOCODE  44  PERSON 

TO  CfiANGE  POSN 

•  IF  .NOT.  FOUNDO 

•  CLEAR. 

•  0  6,0  TO  6,79  DOUBLE 

•  0  7,15  SAY  "IDCODE  DOES  NOT  EXIST, 

PRESS  RETURN  TO  TRY  AGAIN.  .  " 

•  LOOP 

•  ENDIF 

•  REPIACE  TDA_PARA  WITH  M^TDAPARA, 

•  TDA_LINE  WITH  M_T0ALINE,  ; 

•  TDA__POSN  WITH  99 

•  GO  TOP 

•  LOCATE  FOR  IDCODE-OLDPERSON 

•  REPLACE  TDA^POSN  WITH  99  44PUT  THE 

OLDE  PERSON  IN  EXCESS 

•  ELSE 

•  f  6,0  TO  6,79  DOUBLE 

•  0  7,5  SAY  "TDA  POSITION  ENTERED  IS 

NOT  AN  *  AUTHORIZED  TDA  POSITION 

•CHECK  INFORMATION  AND  PRESS  RETURN  TO  TRY 

AGAIN. . . " 

•  WAIT  "  " 

•  LOOP 

•  ENDIF 

•  TRY  -  .F. 

•  LOOP 


CASE  ANSWER*! 


•  LOOP 

•  ENDCASE 

•ELSE  64PERSON  NOT  FOUND ()  IN  POSITION  DESIRED 

•  CLEAR 

•  USE  TDA 

•  LOCATE  FOR  TDA_PARA-M_tDAPARA  .AND. 
TDA_LIN1-M_TDALIHE  .AND.  TDA_POSN*M_TDAP0SN 

•  IF  FOUND ()  44AUTHORXZSO  SLOT 

•  USE  PERSON 

•  LOCATE  FOR  IDCODE^_XOCODE  44  PERSON  TO 

CHANGE  POSN 

•  IF  .NOT.  FOUNDO 

•  CLEAR 

•  •  6,0  TO  6,79  DOUBLE 

«  0  7,15  SAY  "IDCODE  DOES  HOT  EXIST,  PRESS 

RETURN  TO  TRY  AGAIN.." 

•  LOOP 

•  ENDIF 

•  REPLACE  IDA  PARA  WITH  M  TDAPARA, 

•  tda“lime  with  m'tdaline, 

•  TDA_POSN  WITH  M_TDAPOSN 

•  ELSE 

•  0  6,0  TO  6,79  DOUBLE 

•  0  7,5  SAY  "TDA  POSITION  ENTERED  IS  NOT  AN 

AUTHORIZED  TDA  POSITION" 

•CHECK  INFORMATION  AND  PRESS  RETURN  TO  TRY 

AGAIN. . ." 

•  WAIT  "  • 

•  LOOP 

•  ENDIF 

SET  CONFIRM  OFF 
STORE  '  '  TO  walt_«ub»t 

0  23,0  SAY  'Prasa  any  kay  to  continua...'  GET 
wait^aubat 

READ 

SET  CONFIRM  ON 

ENDCASE 

ENDDO  T 
RETURN 

•  EOF:  PKEMU3.PRG 
'“t 


•  Pioqran. . t 

PMnmi.PRo 

•  Author...:  ELBERT  T.  SHAW  4  JOAN  ZII>MERMAN 

•  Data . t  02/02/69 

•  Notlea:  Copyright  (e)  1969, ELBERT  T.  SHAW  4  JOAN 
ZIMMERMAN,  All  Rights  Rasarvad 

•  Kotaa....:  UPDATE  CMS  LIST/BUDGET 

SET  TALK  OFF 
SET  BELL  OFF 
SET  ESCAPE  OFF 
SET  CMVriRM  ON 

DO  WHILE  .T. 

•  - Display  nanu  options,  eantarad  on  tha  acraan. 

•  draw  nanu  bordar  and  print  haadlng 
CLEAR 

02,  0  TO  14,79  DOUBLE 

0  3,  19  SAY  [UPDATE  CHE  INFORMATION] 
0  4,1  TO  4, 76  DOUBLE 

•  >->dlaplay  datall  llnas 

§  7,20  SAY  (1.  Updata  Allocation  for  Fiscal  Yaar] 

0  6,20  SAY  [2.  Updata  CME  Ra<|uasta) 

0  9,20  SAY  [3.  Updata  CME  Raquaata  with  Actual  Coats] 

I  10,20  SAY  [4.  Print  Raporta] 
f  12,  20  SAY  '0.  EXIT' 

STORE  0  TO  aalactnuiB 
0  14,33  SAY  "  aalact 

f  14,42  GET  salactnun  PICTURE  ”9"  RANGE  0,4 
READ 

DO  CASE 

CASE  aalactnun  *  0 
CLEAR  ALL 
RETURN 

CASE  aalactnun  *  1 

•  DO  Updata  Allocation  for  Flaeal  Yaar 

DO  pnanu4_l 

SET  CONFIRM  OFF 

STORE  '  '  TO  walt_aub8t 

0  23,0  SAY  'Prasa  any  kay  to  contlnua...'  GET 
wait_aub8t 

READ 

SET  CONFIRM  ON 
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CXSt  ••l^ctnua  •  2 

*  no  (ipdat*  <34  R«qu«sts 

DO  PMIND4_2 

SIT  CMirilM  OFF 
STORI  '  '  TO  ««lt_sub«t 

t  23,0  SAY  'Fr«s«  any  kay  to  contlnua. . . '  OKT 
walt_aub«t 

MAD 

SIT  CONFIRM  ON 
CASI  aalactnuM  •  3 

*  DO  Dpdata  CMI  Raquaita  with  Actual  Coats 

DO  FMIMD4_3 

SIT  CONFIRM  OFF 
STORX  '  '  TO  walt_aubat 

I  23,0  SAY  'Praas  any  kay  to  eontlnua...'  OIT 
wait  aubst 

RIAD 

SIT  CONFIRM  ON 

CASI  aalaetnum  ■  4 

*  DO  Print  Raporta 

DO  PMINU4_4 

SIT  CONFIRM  OFF 

STORS  '  '  TO  walt^aubat 

i  23,0  SAY  'Praaa  any  kay  to  eontlnua...'  GET 
walt_aubat 

READ 

SIT  CONFIRM  ON 

INDCASt 

INDOO  T 
RITORN 

•  lOFt  PKIND4.PRG 
*1 


•  Pro^raM. . i 

»kBN04_l.tR0 

•  Author...:  lUIRT  T.  SRAM  4  JOAN  ZI>*aRMAN 

•  Data . :  02/02/99 

•  Notlea...:  Copyright  <e)  1989,ILBIRT  T.  saSN  «  JOAN 
SZIMBRMAM,  All  Rights  Ratarvad 

•  Notaa....:  OPOATt  ALLOCATION  FOR  FY 


SIT  TALK  OFF 
SIT  SILL  OFF 
SIT  ISCAPI  OFF 
SIT  CONFIRM  ON 
M_FY  -  0 

*  Claat  Sciaan  for  FY  Input  an  allow  for  tha  uaar  to  aalact 
tha  Fiscal  Yaar 

*  Typically,  tha  uaar  will  only  Oa  oparatlng  in  ona  FY 
CLSAR 

96, 0  to  e, 79  DOUBLE 

97,15  SAY  "Intar  tha  Fiscal  Yaar  for  tha  CKE  Allocations:*'  ; 
OIT  M_FY  PICTURE  "99" 

READ 

DO  miLE  .T. 

*  ---Display  »anu  options,  eantarad  on  tha  scraan. 

*  draw  manu  bordar  and  print  baadlng 
CLEAR 

M  ALLOCATION  •  0 
9”6,0  TO  9,79  DOUBLE 

9  7,15  SAY  "firrEF  RI.LOCATION  FOP  FISCAL  YEAR 
•4STRfM_fY,  2) 

OIT  M^ALLOCATION  PICTURE  "999999.99" 

9  9,15  SAY  "C»  FRIES  RETURN  TO  QUIT" 

READ 

IF  M  ALLOCATION  •  0 
IXIT 
ENDIF 

USE  CMEALLOC 
LOCATE  FOR  FY"M_FY 
IF  FOUND O 
CLEAR 

9  6, 0  TO  8, 79  DOUBLE 

9  7,15  SAY  "ALLOCATION  FOR  FISCAL  YEAR  "♦STR rM_FY, 2» ♦ " 
ALREADY  IXISTS"; 

9  9,15  SAY  "PRISS  RETURN  TO  EDIT  IT" 


WAIT  "  " 

SET  FORMAT  TO  CMEALLOC 
READ 

lAOP 

ELSE  44  ALLOCATION  FOR  FY  IS  A  NEW  ONE 
APPEND  BLANK 

REPLACE  ALLOCATION  WITB  M_ALLOCATION 
RIPLACI  FY  NITB  M_FY 
LOOP 
IMDIF 
IMDDO  T 
RETURN 

*  lOFl  FMENU4_l.PRO 
"I 


*  Program..: 

PIBVQ4_2.nie 

*  Author...:  ELBERT  T.  SRAW  4  JOAN  ZIMMERMAN 

*  Data . :  02/02/89 

*  Notica...:  Copyright  (c)  1989, ELBERT  T.  SBAW  4  JOAN 
ElRtaRMAN,  All  Rights  Rasarvad 

*  Hotas . . . . t  UPDATE  CMI  REQUESTS 


SET  TALK  OFF 
SIT  BELL  OFF 
SET  ISCAPI  OFF 
SET  CONFIRM  OH 
M_FY  •  0 

"  Claar  Scraan  for  FY  Input  an  allow  for  tha  uaar  to  aalact 
tha  Fiscal  Yaar 

*  Typically,  tha  uaar  will  only  ba  oparatlng  In  ona  FY 
CLEAR 

96,0  to  8,79  DOUBLE 

97,15  SAY  "Entar  tha  Fiscal  Yaar  for  tha  CME  Allocations:"  ; 
GET  M_FY  PICTURE  "99" 

READ 

DO  WHILE  .T. 

*  --Display  manu  options,  eantarad  on  tha  scraan. 

*  draw  »anu  bordar  and  print  baadlng 
CLEAR 

92,  0  TO  14,79  DOUBLE 

9  3,21  SAY  [UPDATE  CME  REQUESTS) 

9  4,1  TO  4, 78  DOUBLE 

*  “••'display  datall  Unas 

9  7,30  SAY  [1.  ADD  A  HEW  CME  REQUEST  FOR  FY 

J4STR  fM_FY,  2> 

9  8,30  SAY  [2.  CBANUE  X  CMI  REQUEST'S  INFORMATION  FOP  FY 

J4STR <M_rY, 2) 

9  9,30  SAY  [3.  DELETE  A  CMS  REQUEST  FOR  FY  ]4STR(H  FY,2) 
9  10,30  SAY  [4.  REVIEW  ALL  CMS  REQUESTS  FOR  FY 
)4STR (M_FY,  2) 

9  12,  30  SAY  '0.  EXIT' 

STORE  0  TO  salaotnun 
9  14,33  SAY  "  aalact 

9  14,42  GET  salactnura  PICTURE  "9"  RANGE  0,4 
READ 

DO  CASE 

CASE  salactnun  ■  0 
CLEAR  ALL 
RETURN 

CASE  salactnun  ■  1 
*  DO  ADD  INFORMATION 

DO  WHILE  .T. 

9  6, 0  TO  9, 79  DOUBLE 

9  7,15  SAY  "ENTER  THE  ID  CODE  OF  THE  PERSON  TO  ADD 
THE  P.lQUE.9Tr 

GET  M_IDCODE  PICTURE  "!999" 

9  9,15  SAY  "OP  FPESS  PETUPN  TO  QUIT" 

IF  M  IDCODE-  "" 

EXIT 

ENDIF 

USE  PERSON 

LOCATE  FOR  IDCODE-M  IDCODE 

IF  FOUNDO  44PERS0n'D0ES  EXIST  IN  MASTEP  FILE 
ANSWSP  -  " 

MESSAGE-  "IS  THIS  THE  PERSON  YOU  EXPECTED?  (Y/N> 

SET  FOPMRT  TO  CONTI PM 

READ 
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ir  AHSNER  •  "Y”  Cfttha  right  person 
OSB  CMERBO 

SET  FILTER  TO  rY»M_rY 
0'*>  Tor 

SET  rORHRT  TO  CMBREQ 
APFEND  BLMOC 

RBPIACB  XDCODE  WITH  M_XDCODE 
RIRIACB  fY  WITH  M^FY 

READ 

REFXACE  TOTALCOST  WITH 
TRAVBLC08T«PERDXEM4REaFEEtREZHB 
CLOSE  FORMAT 
SET  FILTER  TO 
LOOP 
ELSE 

LOOP 

ENDZr 

ELSE 

I  6,0  TO  8,79  DOUBLE 

t  7,15  SAY  "TBEPB  IS  NOT  A  PERSON  WITH  TRAT 
XDCODE,  PRESS  RETURN  TO  TRY  AGAIN...” 

WAIT  "  " 

LOOP 

ENDIF 

ENDDO 

SET  CONFIRM  OFF 
STORE  '  '  TO  walt_aubat 

I  23,0  SAY  'Praaa  any  kay  to  contlnua...'  GET 
wait^aubat 

READ 

SET  CONFIRM  ON 

CASE  aalactnum  2 
•  DO  CHANGE  INFORMATION 

DO  WHILE  .T. 

•  6,0  TO  9,79  DOUBLE 

S  7,15  SAY  "ENTER  THE  ID  CODE  OF  THE  PERSON  YOU 
WANT  TO  CHANGE:  "  GET  M_IDCODE  PICTURE  "1999" 

8  9,15  SAY  "OR  PRESS  RETURN  TO  QUIT" 

IF  M  IDCODE-  "" 

EXIT 

ENDIF 

USB  PERSON 

LOCATE  FOR  IDCODE-M^IOCODE 

IF  FOUNDS  aaPERSON'oOBS  EXIST  IN  MASTER  FILE 
ANSWER  •  "  " 

MESSAGE*  "IS  THIS  THE  PERSON  YOU  EXPECTED?  (Y/N» 

SET  FORMAT  TO  CONFIRM 

READ 

IF  ANSWER  *  "Y"  «4tha  right  paraon 
USE  CMEREQ 

SET  FILTER  TO  ZDCOOE-M_IOCODI  .AND.  FY-M  FY 
CLEAR 
9  6,0 

DISPLAY  FIELDS  IDCODE, TYPE, START. END  WHILE 
IDCODE-M_lDCODE 
9  20,  0  CLEAR 

9  22,0  SAY  "ENTER  THE  RECORD  NUMBER  OF  THE 
CME  REQUEST  YOU  DESIRE  TO  CHANGE.  (l-"> 

8TR<RECCOT»«T  ()  ,  4)  +") 

GET  RECORD  PICTURE  "9999" 

READ 

IF  RECORD  >  0  .AND.  RECORD  <  RECCOUNTf) 

CLEAR 

DO  WHILE  .T. 

9  6,0  TO  8,79  DOUBLE 

9  7,5  SAY  "WILL  COSTS  BE  ACTUAL  COSTS  OR 

ESTIMATED; 

(ENTER  AN  -A-  FOR  ACTUAL  OR  AN  -E-  FOR 
ESTIMATED)"  GET  M^CCODE  PICTURE  "1" 

IF  M_CCODE  «  "A"  .OR,  M_CCODE  ♦  "E" 

CLEAR 

9  6, 0  TO  8, 79  DOUBLE 

9  7,15  SAY  "YOU  RAVE  ENTERED  A  WRONG 
LETTER,  PRESS  RETURN  TO  TRY  AGATN.. 

WAIT  ”  " 

LOOP 

ENDIF 

GOTO  RECORD 
SET  FORMAT  TO  CMEREQ 
REPLACE  C  CODE  WITH  M  CCODE 
READ 

REPLACE  TOTALCOST  WITH 
TRAVELCOST-fPERDIEM-fREOFEE-fREIMB 
CLOSE  FORMAT 
EXIT 
ENDDO 
ELSE 

9  20,0  CLEAR 

9  23,5  SAY  "NO  SUCH  RECORD: 

"♦8TR(RECORD, 4) 


7  CHR(7) 

WAIT 

ENDIF 

SIT  FILTER  TO 
LOOP 

ELSE 

SET  FILTER  TO 
LOOP 
ENDIF 

ELSE 

9  6,0  TO  8, 79  DOUBLE 

9  7,15  HAY  "THERE  IS  NOT  A  PERSON  WITH  TRAT 
XDCODE,  PRESS  RETURN  TO  TRY  AGAIN..." 

WAIT  "  • 

LOOP 

ENDIF 

ENDDO 

SET  FILTER  TO 

SET  CONFIRM  OFF 
STORE  '  '  TO  walt_aubat 

9  23,0  SAY  'Praaa  any  kay  to  eontinua...'  GET 
wait_aubat 

READ 

SET  CONFIRM  ON 

CASE  aaladnun  ■  3 
*  DO  REMOVE  INFORMATION 

DO  WHILE  .T. 

9  6,0  TO  9,79  DOUBLE 

9  7,15  SAY  "ENTER  THE  ID  CODE  OF  THE  PERSON  TO 
DELETE  THEIR  REQUEST:  "  GET  M_lDCODl  PICTURE  "1999" 

9  8,15  SAY  "OR  PRESS  RETURN  TO  QUIT" 

IF  M  XDCODE*  "" 

EXIT 

ENDIF 

USB  PERSON 

LOCATE  FOR  lDCODE-M_lDCODE 

IF  FOUND  ()  ttPERSON  DOES  EXIST  IN  MASTER  FILE 
RIGHT  •  "  " 

SET  FORMAT  TO  CMEVAL 
READ 

IF  RIGHT  •  "Y"  44tha  right  paraon 
USB  CMEREQ 

SET  FILTER  TO  XDCODE*M  IDCODE  .AND.  FY^H  FY 
CLEAR 
9  6,0 

DISPLAY  FIELDS  IDCODE, TYPE, START, END  WHILE 
XDCODE*M  IDCODE 
9  20,  ~0  CLEAR 

9  22,0  SAY  "ENTER  THE  RECORD  NUMBER  OF  THE 
CME  REQUEST  YOU  DESIRE  TO  DELETE.  |1> 

"♦STR(RECCOUNT() , 4)+”) "/ 

GIT  RECORD  PICTURE  "9999" 

READ 

IF  RECORD  >  0  .AND.  RECORD  <  PiCCOUNTt) 

GOTO  RECORD 

SET  FORMAT  TO  DELCHBREQ 
READ 

IF  UPPER (MAYBE)-  "Y" 

DELETE 

ENDIF 

CLOSE  FORMAT 
ELSE 

9  20,0  CLEAR 

9  23,5  SAY  "NO  SUCH  RECORD: 

"  +  STR(RECORD,  4) 

7  CBR(7) 

WAIT 

ENDIF 

LOOP 

ELSE 

9  6, 0  TO  8, 79  DOUBLE 

9  7,25  SAY  "THEPC  IS  NOT  A  PERSON  WITH  THAT 
XDCODE,  PRESS  RETURN  TO  TRY  AGAIN...” 

WAIT  "  " 

L^'T 

ENTIF 

ENDDO 

SET  FILTER  TO 
SET  TALK  ON 
CLEAR 

9  2,0  SAY  '  ’ 

?  'PACKING  DATABASE  TO  REMOVE  RECORDS  MARKED  FOP 
DELETION' 

PACK 

SET  TALK  OFF 

SET  CONFIRM  OFF 

STORE  '  '  TO  wait_9ubtt 

9  23,0  SAY  'Frass  any  kay  to  contlnua...'  GET 
aalt^subat 

READ 
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SIT  C<»9FIFM  ON 

CASE  ••l«ctnuni  ■  4 
•  no  Fr  irw  ^nr^^M^TTON 

SILICT  A 
OSS  CMSRIQ 

INDEX  ON  IDC<»B  TO  TEMP 
SELECT  8 
OSB  PBASON 

INDEX  ON  IDCOOB  TO  TEMPI 

JOIN  WITH  A  TO  TBMPJOZN  FOA  IDCOOX«A->XDCOOE  rilLDS 
A->IDC0DB,B->AANK, B->rHAMB. ; 

B~>LNAME,  A->TYPE,  A->8TAAT,  A->END,  A->LOCATION,  A- 
>POEPOSI,; 

A->>TVLCOST,  A'>PBRDIEM,  A-<>RXOrBB ,  A->RXIMB ,  A- 
>TOTALCOST,  ; 

A->C_COOE,A->rY 
OSB  TSMPJOZN 
SET  FILTER  TO  FY-M_FY 
BROWSE  NOAPPEND  NOMENO 
ERASE  TBMP.NDX 
ERASE  TEMPI. NDX 
ERASE  TBMPJOZN. DBF 
SET  CONFIRM  OFF 
STORE  '  *  TO 

t  23,0  SAY  'Pr«««  «ny  kmy  to  continu*. GET 
w«lt_subst 

READ 

SET  CONFIRM  ON 

BNDCASB 

INDDO  T 
RBTORN 

*  BOFi  PMBN04_2.PR0 


•  Program..} 

»lBN04_3.fM 

•  Author...:  ELBERT  T.  SHAN  4  JOAN  ZIM4ERMAN 

•  Data .  02/02/89 

•  Notlca...:  Copyright  <c)  Ises.ELBSRT  T.  SHAN  «  joan 
ZI»t4ERMAN.  All  Right*  Rasarvad 

•  Nota*....}  OPDATE  CMB  REOOEST  WITH  ACTOAL  COSTS 


SET  TALK  OFF 
SET  BELL  OFF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 
M_FY  •  0 

*  Claar  Scraan  for  FY  Input  an  allov  for  tha  u*ar  to  aalaet 
tha  Fiscal  Yaar 

*  Typically,  tha  usar  will  only  ba  operating  in  ona  FY 
CLEAR 

#6,0  to  8,79  DOUBLE 

#7,15  SAY  "Bntar  tha  Fiscal  Yaar  for  tha  CME  Allocation*:"  ; 
GET  M_FY  PICTURE  "99" 

READ 

DO  NBZLE  .T. 

#  —Display  nanu  options,  cantarad  on  tha  scraan. 

#  draw  Mnu  bordar  and  print  haadlng 
CLEAR 

M_IDCODE  •  SPACE <$) 

RECORD  -  0 

#  6,0  TO  8,79  DOUBLE 

#  7,15  SAY  "ENTER  THE  ID  COTE  OF  THE  PERSON  YOU  WANT  TO 
UPDATE  WITH  ACTUAL  COST  OF  TRAVEL"; 

GET  M  IDCODB  PICTURE  "1999" 

READ  " 

USE  CMERKQ 

SIT  FILTER  TO  IPCODE«M_IDrODE  .AND.  rY-M_rY 
CLEAR 

#  6,0 

DISPLAY  FIELDS  ZDCODE, TYPE, START, END  WHILE 
IDC(»B>M_I0CODE 

#  20,  0  CLEAR 

#  22,0  SAY  "ENTER  THE  RECORD  NUMBER  OF  THE  CME  REQUEST 
YOU  DESIRE  TO  CHANGE.  (1 -"4STR  <RECCOUNT  < )  ,  4M" ) 

GET  RECORD  PICTURE  "9999" 

READ 

IF  RECORD  >  0  .AND.  RECORD  <  RECCOUNTO 
GOTO  RECORD 

SET  FORMAT  TO  UPCHEREO 
REPLACE  C_COOE  NXTH  A 
READ 


REPLACE  TOTALC08T  WITH  TRAVELCOST<fPERDIBH+REGFEEtREI>S 
CLOSE  FORMAT 

ELSE 

#  20.0  CLEAR 

e  :j,5  CAi  -NO  Sncii  RirORDl  •♦STP  (RECOPr,  4) 

7  CBR(7) 

WAIT 
ENDIF 
BNDDO  T 
RETURN 

*  EOF:  PHEMU4_3.PRO 

*2 


*  Program. . i 

rMBnJ4_4.fRO 

*  Author...:  ELBERT  T.  SHAN  4  JOAN  Ztff4ERMAN 

*  Data .  02/02/89 

*  Notlca...:  Copyright  (e)  1989,  ELBERT  T.  SHAN  t  JOAN 
SlIMERMAM,  All  Rights  Rasarvad 

*  Notas . . . . :  PRINT  CME  REPORTS 


SET  TALK  OFF 
SET  BELL  OFF 
SET  ESCAPE  Off 
SET  CONFIRM  ON 
M_FY  -  0 

*  Claar  Scraan  for  FY  Input  an  allow  for  tha  usar  to  salact 
tha  Fiscal  Yaar 

*  Typically,  tha  usar  will  only  ba  operating  In  ona  FY 
CLEAR 

#6,  0  to  8,  79  DOUBLE 

#7,15  SAY  "Bntar  tha  Fiscal  Yaar  for  tha  CME  Allocations:"  ; 
GET  M_FY  PICTURE  "99" 

READ 

DO  WHILE  .T. 

*  OnDisplay  manu  options,  cantarad  on  tha  scraan. 

*  draw  manu  bordar  and  print  haadlng 
CLEAR 

#2,  0  TO  11,79  DOUBLE 

#3. 23  SAY  (PRINT  CME  REPORTS) 

#  4,1  TO  4,78  DOUBLE 

ft  —display  datall  linas 

#  7,30  SAY  (1.  ESTIMATED  CMB  EXPENSES  REPORT  FOR  FY) 
4^8TR(M  Fy,2) 

•  8, 30 'say  [2.  ACTUAL  CME  EXPENSES  REPORT  FOR 
FY)4STR(M  FY,  2) 

#  10,34  SAY  '0.  EXIT' 

STORE  0  TO  salactnum 

8  11,33  SAY  "  salact 

I  11,42  GET  salactnum  PICTURE  "9"  RANGE  0,0 

READ 

DO  CASE 

CASE  salactnum  *  0 
CLEAR  ALL 
RETURN 

CASE  8ELECTNUM  •  1 

•JOIN  CMEPEQ  WITH  PERSON  TO  JOINFILE  FOR  IDCOOE 

•USE  CNEALLOC  AND  GET  ALLOCATION  FCNl  SELECTED  FY 

•STORE  ALLOCATION  TO  FY_ALLOCATX0W 

•USE  JOINFILE  INDEXED  ON  START  DATE 

•SET  FILTER  TO  FY«M  FY 

•STM  TOTAL  FOR  C_cdoi»"A"  TO  A_TOTAL 

•SUM  TOTAL  FOR  C  CODE»"E"  TO  B  TOTAL 

•REPORT  WILL  DISPLAY  FYJkLLOCATIQN  LESS  A  TOTAL  AND 

•  TOTAL  ESTIMATED  COSTS  REMAINING,  B_T^AL 

• 

•ESTIMATED  CME  REPORT  PRINTED  HERE 
CASE  SELECmUH  -  2 

•JOIN  CMEREQ  WITH  PERSON  TO  JOINFILE  FOR  IDCODE 

•USB  CNEALLOC  AND  GET  ALLOCATION  FOR  SELECTED  FY 

•STORE  ALLOCATIW  TO  FY_ALLOCATICtl 

•USB  JOINFILE  INDEXED  ON  START  DATE 

•SET  FILTER  TO  FY-M  FY 

•SUM  TOTAL  FOR  C_CODE*"A"  TO  A  TOTAL 

•SUM  TOTAL  FOR  C_CODE-"E"  TO  e”T0TAL 

•SET  FILTER  TO 

•SET  FILTER  TO  C_CODE»"A"  .AND.  rY^_rY 
•REPORT  WILL  DISPLAY  FY  ALLOCATION  LESS  A_TOTAL 
•BUT  WILL  NOT  DISPLAY  ESTIMATED  ENTRIES 
•TOTAL  ESTIMATED  COSTS, E_TOTAL,  REMAIHINO  WILL  BE  A 
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C0M4BIIT  AT  BOTTOM 

*  or  RBPOFT 

• 

*ACT”lkL  nv.  PFPapt  rPTMTFn  BCFE 

B1«DCA8B 

IMDDO  T 
RBTOIW 

•  BOrt  PMBNU4_4.PR6 
''Z 


*  Progran. . i 

PIBIIUS.PBO 

*  Anther...;  BLBERT  T.  SHAN  4  JOAN  ZZM4ERMAM 

*  D*t» . ;  02/02/89 

*  Metioe...:  Copyright  (e)  1989,  ELBBRT  T.  8RAII  4  JOAM 
ZXttaRMAH,  All  Right!  R«!«rv«d 

*  Mote*....:  UPDATE  LEAVE /ABSBHSE  REQUESTS 

SET  TALK  orr 

SET  BELL  orr 

SET  ESCAPE  orr 
SET  court RM  ON 
USE  ABSENCE 
M_rY  -  0 

*  Cleer  Screen  tor  rY  input  an  allow  for  the  user  to  select 
the  riseal  Year 

*  Typically,  the  user  will  only  be  operating  in  one  rY 
CLEAR 

86,0  to  8,79  DOUBLE 

87,15  SAY  "Enter  the  riacal  Year  for  the  CME  Allocations t"  ; 
GET  M_rY  PICTURE  "99" 

READ 

DO  WHILE  .T. 

*  •o-Dlsplay  aenu  options,  centered  on  the  screen. 

*  draw  aenu  border  and  print  heading 
CLEAR 

82,  0  TO  14,79  DOUBLE 

8  3, 12  SAY  [UPDATE  LEAVE/ABSENCE  LI 
S  T  I  N  G  SJ 

8  4,1  TO  4,78  DOUBLE 

*  - display  detail  lines 

8  7,30  SAY  [1.  ENTER  A  NEW  LEAVE  REQUEST  FOR  PY 

J+STR <M_rY, 2# 

8  eTsO  SAY  (2.  CHANGE  CURRENT  LEAVE  INTORMATION  POR  PY] 
♦STR(M_rY,2) 

8  9,30  SAY  [3.  REMOVE  A  LEAVE  REQUEST  PROM  PY 

J-fSTR  (M_PY,2) 

8  lOTsO  SAY  [4.  REVIEW  LEAVES  FOR  FY  ] tSTR (M^FY, 2) 

8  12,  30  SAY  '0.  EXIT' 

STORE  0  TO  seleetnure 
8  14,33  SAY  "  select 

8  14,42  GET  seleetnum  PICTURE  "9"  RANGE  0,4 

READ 

DO  CASE 

CASE  seleetnum  «  0 
CLEAR  ALL 
RETURN 

CASE  seleetnum  «  1 
*  DO  ADD  INTORMATION 
USE  ABSENCE 
DO  WHILE  .T. 

8  6,0  TO  9,79  DOUBLE 

8  7,15  SAY  "ENTER  THE  ID  CODE  OF  THE  PERSON  TO  ADD 
THE  LEAVE  REQUEST;  "  GIT  M^IDCODE  PICTURE  "J999" 

8  8,15  SAY  "OR  PRESS  RETURN  TO  QUIT" 

IP  M  IDCODE*  "" 

EXIT 

ENDir 

USE  PERSON 

LOCATE  FOR  lDCODE-M_IDCODE 

ir  FOUND ()  44PERSON  DOES  EXIST  IN  MASTER  PILE 
ANSWER  -  -  " 

MESSAGE*  "IS  THIS  THE  PERSON  YOU  EXPECTED?  (Y/N) 

SET  FORMAT  TO  CONFIRM 

READ 

IF  ANSWER  *  "Y"  44the  right  parson 
USE  ABSENCE 
SET  FILTER  TO  rY-M__FY 
GO  TOP 

SET  FORMAT  TO  ABSENCE 
APPEND  BLANK 

REPLACE  IDCODE  WITH  M  IDCODE 


REPLACE  PY  WITH  M  FY 
READ 

REPLACE  DURATION  WITH  END-START 

CLortf 

SET  FILTER  TO 
LOOP 
ELSE 

LOOP 

ENDir 

ELSE 

8  6,0  TO  8,79  DOUBLE 

8  7,15  SAY  "THERE  IS  ROT  A  PERSON  WITH  THAT 
IDCODE,  PRESS  RETURN  TO  TRY  AGAIN.  .  ." 

WAIT  "  • 

LOOP 

ENDir 

ENDDO 

APPEND 

SET  COHPIRM  OFF 
STORE  '  '  TO  walt_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait^subst 

READ 

SET  CONFIRM  ON 

CASE  seleetnum  -  2 
*  DO  CBANOE  INFORMATION 

DO  WHILE  .T. 

8  6,0  TO  9,  79  DOUBLE 

8  7,15  SAY  "ENTER  THE  ID  CODE  OP  THE  PERSON  YOU 
WANT  TO  CHANGE:  "  GET  H  IDCODE  PICTURE  "1999" 

8  8,15  SAY  "OR  PReA  return  TO  QUIT" 

IF  M  IDCODE*  "" 

EXIT 

ENDir 

USE  PERSON 

LOCATE  FOR  IDCODK*M  IDCODE 

IP  POUND ()  44PER80N~DOKS  EXIST  IN  MASTER  FILE 
ANSWER  -  -  " 

MESSAGE-  "IS  THIS  THE  PERSON  YOU  EXPECTED?  (Y/N) 

SET  FORMAT  TO  CONFIRM 
READ 

IP  ANSWER  •  "Y"  «4the  right  person 
USE  ABSENCE 
CLEAR 
8  6,0 

DISPLAY  FIELDS  IDCODE, TYPE, START, END  WHILE 

1DC0DE*M_IDC0DE 

~  8  20,  0  CLEAR 

8  22,0  SAY  "ENTER  THE  RECORD  NUMBER  OP  THE 
LEAVE  REQUEST  YOU  DESIRE  TO  CHANGE.  (1>"  * 

5TR (RECCOUNT O  /  4) +•) "; 

GET  RECORD  PICTURE  "9999" 

READ 

IP  RECORD  >  0  .AND.  RECORD  <  RECCOUNTO 
CLEAR 

GOTO  RECORD 

SET  FORMAT  TO  ABSENCE 

READ 

REPLACE  DURATION  WITH  END-START  44COMPOTt 
♦  OP  DAYS 

CLOSE  FORMAT 
EXIT 
ENDDO 
ELSE 

8  20.0  CLEAR 

8  23,5  SAY  "NO  SUCH  RECORD: 

•♦STR<RECORD, 4) 

7  CaR<7) 

WAIT 

ENDir 

SET  FILTER  TO 
LOOP 

ELSE 

SET  FILTER  TO 
LOOP 
ENDIF 

ELSE 

8  6,0  TO  8,79  DOUBLE 

8  7,15  SAY  "THCPE  IS  NOT  A  PERSON  WITH  THAT 
IDCODE,  PRESS  RETURN  TO  TRY  AGAIN..." 

WAIT  "  " 

LOOP 

BNDXP 

ENDDO 

SET  PILTEP  TO 

SET  CONFIRM  OFF 

STORE  '  '  TO  walt_8Ub8t 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait  subst 
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RBAD 

<IT  COHTIKM  ON 

CASK  ••l»ctnuM  •  3 

OO  1UU40V1  INFORHATION 

DO  IIBILB  .T. 

9  9,0  TO  9,19  DOUBLE 

«  7,15  SAY  "EHTBR  TfiE  ZD  CODE  Of  TBE  PERSON  TO 
TBIIR  LEAVE  RSOUESTt  ”  SET  M^IDCODE  PICTURE 

•  $,1$  SAY  "OR  PRESS  RBTURB  TO  QUIT” 

IF  M  IDCODE-  "" 

EXIT 

EMDir 

USE  PERSON 

LOCATE  FOR  IDCODE«N_IDCODE 

IF  FOUND  0  StPERSON  DOBS  EXIST  IN  MASTER  FILE 
ANSWER  •  "  " 

MXSSAOE-  "IS  THIS  THE  PERSON  YOU  EXPECTED?  (Y/H) 

SET  FORMAT  TO  CONFIRM 

READ 

IF  ANSWER  -  "Y"  44th«  light  p«raon 
USE  ABSENCE 

SET  FILTER  TO  1DCODE-M_IOCODE  ,AND.  FY^_FY 
CLEAR 
«  6,0 

DISPLAY  FIELDS  IDCODE, TYPE, START, END  WBILE 
ZDCODEa44_IDCODE 
I  20,  0  CLEAR 

I  22,0  SAY  "ENTER  THE  RECORD  NUMBER  OF  TBt 
RIOUEST  YOU  DESIRE  TO  DELETE .  (l-"+ 

STR ( RECCOUNT  0,4)+")"; 

GET  RECORD  PICTURE  ”9999" 

READ 

IF  RECORD  >  0  .AND.  RECORD  <  RECCOUNT () 

GOTO  RECORD 
SET  FORMAT  TO  DBLLEAVE 
READ 

IF  UPPER<MAYBE)«  "Y" 

DELETE 
BNDIF 

CLOSE  FORMAT 

ELSE 

«  20,0  CLEAR 

I  23,5  SAY  "NO  SUCB  RECORD: 

"<fSTR<RECORD,  4) 

?  CBF<7) 

WAIT 

ENDIF 

LOOP 

ELSE 

€  6,0  TO  8,79  DOUBLE 

%  7,15  SAY  "TBERE  IS  NOT  A  PERSON  WITH  THAT 
IDCODE,  PRESS  RETURN  TO  TRY  AGAIN..." 

WAIT  "  " 

LOOP 

ENDIF 

ENDDO 

SET  FILTER  TO 
SET  TALK  ON 
CLEAR 

I  2,0  SAY  '  ' 

7  'PACKING  DATABASE  TO  REMOVE  RECORDS  MARKED  FOR 
DELETION' 

PACK 


DELETE 

"1999" 


LEAVE 


ERASE  TEMP JOIN. DBF 
SET  CONFIRM  OFF 
STORE  '  '  TO  »«4lt_aub?t 

#  "3, I"  .CAY  COftt<nu#...'  OfT 

W4it_siibet 

READ 

SET  CONFIRM  ON 

EHDCASE 

ENDDO  T 
RETURN 

*  EOF:  PMEHUS.PRO 


*  ProgrMb. .  t 

nODfVS.FM 

«  Author...:  ELBERT  T.  SBAW  4  JOAN  EI»MERMAN 

*  D«t* . :  02/02/89 

*  Notlcu...:  Copyright  (c)  1989,  ELBERT  T.  SBAW  4  JOAN 
EXMaRMAN,  All  Right*  R«a«rv«d 

*  Notua....:  PRINT  PERSONNEL  REPORTS 
SET  TALK  OFF 

SET  BELL  OFF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 
DO  WBILE  .T. 

M__FY  -  0 

*  Cl*«r  Scraan  for  FY  input  an  allow  for  tha  uaar  to  aalaet 
tha  Fiacal  Yaar 

*  Typically,  tha  uaar  will  only  ba  oparating  in  ona  FY 
CLEAR 

*  6,0  to  8,  79  DOUBLE 

•7,15  SAY  "Entar  tha  Fiacal  Yaar  for  tha  CME  Allocatlona t "  ; 
GET  M_FY  PICTURE  "99" 

READ 


•  . — Display  nanu  options ,  eantarad  on  tha  sctaan. 

•  draw  Btanu  berdar  and  print  baadiiig 
CLEAR 

•  2,  0  TO  17,79  DOUBLE 

•  3,21  SAY  [PRINT  REPORTS  FOR 
J4STR(M  FY,2) 

t  4,1  TO  4,78  DOUBLE 
«  . — display  datall  linas 

•  7,24  SAY  [1.  Position  Listing) 

•  8,24  SAY  [2.  Saetion  Updata  WorXshaat) 

•  9,24  SAY  [3.  Loss  Raport) 

•  10,24  SAY  [4.  Vacancy  Listing] 

•  11,24  SAY  [5.  Social  Restar] 

•  12,24  SAY  [7.  Monthly  Absanea  Raport) 

§  13,24  SAY  [8.  Doctor  Fiscal  Yaar  Absanea  Sunnary] 

•  15,  24  SAY  '0.  EXIT' 

STORE  0  TO  salactnun 

•  17,33  SAY  "  salact 

•  17,42  GET  salactnun  PZCTUP.B  "9"  RANGE  0,8 
READ 

DO  CASE 

CASE  salactnun  »  0 
CLEAR  ALL 
RETURN 

CASE  salactnun  »  1 
*  DO  Position  Listing 


SET  TALK  OFF 

SET  CM9FZRM  OFF 

STORE  '  '  TO  wait^subst 

I  23,0  SAY  'Prass  any  kay  to  continua...'  GET 
walt^subst 

READ 

SET  CONFIRM  ON 

CASE  salactnun  >  4 
*  DO  REVIEW  INFORMATION 
SELECT  A 
USB  ABSENCE 

INDEX  OH  IDCODE  TO  TEMP 

SELECT  B 
USE  PERSON 

INDEX  ON  IDCODE  TO  TEMPI 

JOIN  WITS  A  TO  TBMPJOXN  FOR  IDCODE<iA->IDCODE  FIELDS 

A>>IDCODE,B*>RAHK,B->rNAHE,  ; 

B->LRAME ,  A->TYPE ,  A->8TART,  A->END ,  A->DURATION,  ; 
A->C0WMENT,  A->PY 
USE  TEMPJOXN 
SET  FILTER  TO  FY-M  FY 
BROWSE  MOAPPEND  NOMENU 
ERASE  TEMP.NDX 
ERASE  TEMPI. NDX 


•JOIN  AFC  WIta  IDA  TO  TEMPJOIN 

•JOIN  TEMPJOIN  WITB  PERSON  FOR  LIKE  TDA  INFORMATION 
•SORT  BY  TDA  POSITION  INFORMATION 
•SUBTOTAL  AUT8  ON  CBANGB  OF  TDA  PARA 
•COUNT  NUMBER  OP  RECORDS  IN  EACB  PARAGRAPH  TO  GET 
ASSIGNED 

•POSITION  LISTING  REPORT  PRINTED  HERE 
•ERASE  ALL  TEMP  FILET 

SET  CONFIRM  OFF 

ST?FE  ■  ■  I'.'  walt^subst 

•  23,0  SAY  'Prass  any  kay  to  continua...'  GET 
walt_^subst 

READ 

BET  CONFIRM  ON 

CASE  salactnun  «  2 
•  DO  Saetion  Updata  Listings 


•JOIN  ARC  WITH  TDA  TO  TEMPJOIN 

•JOIN  TEMTJOIN  WITH  FEPSON  FOR  LIKE  TDA  IKFORMkTlON 
•SORT  BY  TDA  POSITION  INFORMATION 
•SUBTOTAL  AUTH  ON  CHANGE  OF  TDA^PARA 
•COUNT  HUMBER  OF  RECORDS  IN  EACB  PARAGRAPH  TO  GET 
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ASSIOHID 

*80RT  BY  SSCTXON  CODE  TO  GET  SECTION  BREAKOUTS, 
SECONDARY  SORT  BY  TDA  INTORMATION 
•INCLUDE  BLANK  CBANGE  riELOS.  TEE  EXAMPLE  REPORT 
•SECTION  UPDATE  NORKSBECT  REIORT  IRIUICO  HERE 
•BRASS  ALL  TEMP  PILES 
SET  COMTIRM  OPP 
STORE  '  '  TO  walt_sub8t 

•  23,0  SAY  'Pr*a«  any  kay  to  contlnua...*  OET 
walt^^aubat 

~  READ 

SET  COMTIRM  ON 


CASE  saXactaua  •  3 
*  DO  Loaa  Raport 


Start Data 

STORE  SPACE<S)  TO  StartData, EndData 
CLEAR 

16,0  to  9,79  DOUBLE 

#7,15  SAY  "Bntar  tha  start  data:"  ; 

SET  StartOata  PICTURE  *99/99/99" 

#  6,15  SAY  "Bntar  tha  andin^  data:"; 

GET  BndData  PICTURE  "99/99/99” 

READ 

STORE  CTOD<Startdata)  TO  StartData 
STORE  CTOD(EndData)  TO  EndData 

•JOIN  TDA  WITS  PBRSW  TO  TEIff JOIN  TOR  SAME  TDA 

POSITION 

•FIELDS 

RANK,  LMAME,  PNAMB,  JOBTXTLE,  ALOSS,TDA_PARA,  LINE,  AND  POSN 
•USE  TBMPJOIH  4CLIST  OP  ALL  PERSONS  NITH  TBEXR 


JOBTITLE 


•INDEX  ON  ALOSS 
•SEEK  8TAR1DATE 

•—DECIDE  NHETHER  TO  PROCEED  MlTfl  SEEK  APPROACB 

•  - OR  REVERT  TO  SLOWER,  SAFER  FOR  APPROACB 

•IP  POUMDO 

•  LIST  WHILE  ALOSS  <-  8TARTDATE 

•  IP  P08N«99 

•  USE  TDA 

•  LOCATE  TDA_PARA  .AND.  TDA  LINE 

•  PRINT  JOBTITLE 

•  BNDIP 
•ELSE 

•  LIST  FOR  ALOSS  >«  STARTDATE  .AND.  ALOSS  <• 

ENDDATE 

•  IP  PO$N«99 

•  USE  TDA 

•  LOCATE  TDA_PARA  .AND.  TDA_LINE 

•  PRINT  JOBTITLE 

•  EKDIP 
•BNDIP 

•LOSS  REPORT  PRINTED  BERE 
•ERASE  ALL  TEMP  PILES 
SET  CONFIRM  OPP 
STORE  '  '  TO  walt^subst 

•  23,0  SAY  'Praas  any  kay  to  contlnua...'  OET 
walt__8ubst 

READ 

SET  CONFIRM  ON 


CASS  salactnura  •  4 
*  DO  Vacancy  Liattn^ 

•BLANK  •  "  " 


•JOIN  APC  WITH  TDA  TO  TEMPJOIN 
•JOIN  PERSON  WITH  TEMPJOIN  FOR  LIKE  TDA 
INFORMATION,  IF  NO  PERSON 

*  MATCHES  A  IDAPOSITION,  LEAVE  IDCODE  AND  LNAME 

BLANK 

•SORT  BY  TDA  POSITION  INFORMATION 

•COUNT  FOR  INAMB  •  BLANK  .AND.  IDCODE  -  BLANK  TO 
TOTALJ/ACANT 

•SET  FILTER  TO  IDCODB^BLANK  .AND.  LNAME-BLANK 

*  THIS  SHOULD  ONLY  DISPLAY  THE  VACANT  TDA 

POSIT!  CW9S 

•VACANCY  REPORT  PRINTED  HERE 
•ERASE  ALL  TEMP  PILES 
SET  CONFIRM  OPP 
STORE  '  '  TO  walt_aubat 

*  23,0  SAY  'Praaa  any  kay  to  contlnua...'  OET 
wait  aubat 

READ 

SET  CONFIRM  ON 

CASE  aalactnun  ■  5 
•  DO  Social  Roatar 


wait  aubat 

READ 

SET  CONFIRM  ON 

CASE  aalactnun  •  6 

•  DO  MONTHLY  ABSENCE  REPORT 

MONTH  •  0 

6  8,15  SAY  "ENTER  MONTH  (l.a.  1-12)  FOR  THE 

REPORT: 

GET  MONTH  PICTURE  "99  "  RANGE  1,12 

READ 

•USB  ABSENCE 

•COPY  TO  TEWPILE  FIELDS 
IDCODE, START, END , DURATION, FY, TYPE 
•USB  CMEREO 

•COPY  TO  APPENDFILE  FIELDS 
IDCODE, START, END, DURATION, PY, TYPE 
•USB  TBMPPILE 

•APPEND  PRCM  APPENDFILE  JOIN  CME  AND  LEAVE 

FILES 

•SORT  BY  "START"  DATE,  "END"  DATE 
•JOIN  PERSCN  WITH  TEMPPILE  TO  WHOFILE  <«  JOINS 
NAMES  WITH  IDCODE 

•USE  WHOFILE 
•SET  FILTER  TO  FY«ai_FY 

•DISPLAY  WHILE  [MONTH  OP  END  DATE]  -  MONTH  .OR. 
[MONTH  OF  START  DATE)  -  MONTH 

•MONTHLY  ABSENCE  REPORT  PRINTED  BERE 

•ERASE  ALL  TEMP  FILES 

SET  CONFIRM  OFF 

STORE  '  '  TO  walt_Bubat 

•  23,0  SAY  'Praaa'any  kay  to  contlnua...'  OET 
wait_aubat 

READ 

SET  CONFIRM  ON 

CASE  aalactnun  •  7 

•  DO  DOCTOR  ABSENCE  REPORT 
M^PY  -  0 

CLEAR 

#6, 0  to  8, 79  DOUBLE 

#7,15  SAY  "Entar  tha  Placal  Yaar  for  tha  ABSENCE 
REPORT: •  ; 

OET  M_FY  PICTURE  "99" 

READ 

•USX  ABSENCE 

•COPY  TO  TEMPPILE  FIELDS 

IDCODE, START, END. DURATION, FY.TYPE  •USE  CMEREQ 

•COPY  TO  APPENDFILE  FIELDS 
IDCODE , START , END , DURATI ON , P Y ,  Tff E 
•USE  TEMPPILE 

•APPEND  FROM  APPENDFILE  44  JOIN  CME  AND  LEAVE 

FILES 

•SORT  BY  "START"  DATE,  "END"  DATE 
•JOIN  PXR5C»<  WITH  TEMPFILE  TO  WSOPILS  44  JOINS 
NAMES  NITH  IDCODE 

•USB  WHOFILE 
•SET  FILTER  TO  PY-M  PY 
•INDEX  OH  IDCODE 

•AVERAGE  DURATION  TO  AVODUPATION 

•TOTAL  ON  IDCODE  TO  TOTALSUH  FIELDS  DURATION  440X1 
TOTAL  OP  ALL  ABSENCES 

•ABSENCE  StM4ARY  REPORT  PRINTED  HERE,  PROCEDURE 

TED  BELOW 

•DO  WHILE  .NOT.  EOF()  44  SEE  ABSENCE  SUMIARY  REPORT 

•  IP  IDCC^E  HAS  CHANGED  PROM  PREVIOUS  IDCCN}E 

•  -.U5E  TOTALSUM 

•  LOCATE  CURRENTIDCODE 

•  PRINT  "TOTAL  PAYS  ABSENT"+STR (DURATION, 3) 

•  EHDXP 

•  DISPLAY  CURRENT  RBCORD  ’’ 

•  SKIP  TO  NEXT  RECORD 

•BNDDO 

•ERASE  ALL  TEMP  PILES 
SET  CONFIRM  OPP 
STORE  '  '  TO  walt^aubat 

•  23,0  SAY  'Praaa  any  kay  to  contlnua...'  GET 
valt^aubat 

READ 

SET  CONFIRM  ON 

XNDCA8B 
XNDDO  T 
RETURN 

•  E.OPi-  W«NUr.  pRG 
"E 


•JOIN  PRIVATE  WITH  PERSON  TO  SOCIAL  FOR  IDCODE 

•SOCIAL  ROSTER  PRINTED  HERE 

•ERASE  ALL  TEMP  PILES 

SET  CONFIRM  OPP 

STORE  '  '  TO  wait_aubst 

#  23,0  SAY  'Praaa  any  kay  to  contlnua...'  GET 
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APPENDIX  r.  SATISFACTION  PROGRAMS 


fABLi  or  rnosMMi 

aOMU.PRO 
8MBMU2.PRO 
SHBiro2_l .  PRO 
»IBN02_2 .  PRO 
8MBNU2  3. PRO 


DzaeuanBR 

The  purpose  of  this  programning  code  is  to 
facilitate  the  understanding  of  the 
requirements  presented  in  Chapter  5  of  this 
thesis.  The  nature  of  this  project  precludes 
it  actual  inpleitientation  in  DBASE  III-*-.  To 
fully  inclement  the  requirements  the  system 
designer  will  need  a  full  range  of  capabilities 
that  does  not  currently  exist  in  DBASE  III*. 

DBASE  III*  served  as  the  modeling  tool  by 
which  the  screens  were  generated  and  where 
necessary,  specific  code  was  written  to 
illustrate  a  point.  The  actual  working  code 
merely  acts  as  a  sheii  in  which  to  run  the 
menus.  A  close  analysis  of  the  progr^un  code  can 
facilitate  inplementation  in  a  more  suitable 
language,  i.e.,  PARADOX,  which  can  support  the 
graphics  and  high  level  relationships  involved 
in  the  various  databases.  Where  the  actual 
requirements  process  may  appear  to  be  unclear, 
comments  were  added  within  the  T?ode  to  explain 
these  -areas  to  the  designer. 


•  Progrm. .  t 

aw.  PRO 

•  Author...]  JOAN  ZlMaRMAN  4  ELBSRT  SHAM 

•  . .  02/19/99 

•  Hotica...]  Copyright  (c)  1999,  All  Rights  Rasarvad 
■  Motaa....]  Survay  Main  Manu  Program 

SIT  TALK  orr 
SIT  BILL  orr 
SIT  STATUS  orr 
SIT  BSCAPB  orr 

SIT  COHPXRM  ON 
USE  SURVBY 
DO  mXLB  .T. 


•  - Display  nartu  options,  cantarad  on  tha  seraan. 

•  draw  laanu  bordar  and  print  haadlng 
CLtAR 

f  2,  0  TO  12,79  DOUBLE 

t  3,10  SAY  (DIPARnONT  Or  rAMILY  PRACTICE  PATIENT  OPINION 
SYSTEM] 

t  4,1  TO  4,79  DOUBLE  .  . 

•  —-display  datail  linas 

•  ^,28  SAY  tl-  ENTER  NEN  SURVEY  DATA] 
t  9,28  SAY  IZ.  PRINT  OPINION  FESTn,TSJ 

•  10,  28  SAY  '0.  EXIT- 
STORE  0  TO  salactnum 

•  12,33  SAY  ”  salact 

•  12,42  OET  salactnum  PICTURE  "9"  RANGE  0,2 

READ 

DO  CASS 

CASE  salactnum  ■  0 
SET  BELL  ON 
SET  TALK  ON 
CLEAR  ALL 
RETURN 

CASE  salactnum  •  1 
•  DO  INTER  NEN  SURVBY  DATA 


SET  rORMAT  TO  SURVBY 

APPEND 

CLOSE  rORMAT 

SET  comriRM  orr 
STORE  '  '  TO  walt_subst 

t  23,0  SAY  'Prass  any  Ray  to  continue...'  GET 
tfalt_aubst 

READ 

SET  CONTIRH  OH 

CASE  salactnum  •  2 
•  DO  PRINT  OPINION  RESULTS 

DO  8MBNU2 

SET  CONTIRH  OPr 
STORE  '  '  TO  walt^BUbst 

9  23,0  SAY  'Prass  any  kay  to  contlnua...'  GIT 
wait^subst 

READ 

SET  CONTIRH  ON 

BNDCASB 

BMDDO  T 
RETURN 

*  EOT}  SHBNU.PRO 


*  Program. ,  r**^"^**-  * 

MMU2.PRO 

*  Author...]  JOAN  EIMMERHAN  4  ELBERT  SEAN 

*  Data . ]  02/19/99 

*  Netlea...]  Copyright  (c)  1989,  All  Rights  Rasarvad 

*  Notas....!  Print  Opinion  Results 

SET  TALK  orr 
SET  BELL  orr 
SET  STATUS  OTT 
SET  ESCAPE  orr 
SET  CONTIRH  ON 
USB  SURVEY 

DO  NBILB  .T. 

*  - Display  manu  options,  cantarad  on  tha  seraan. 

*  draw  manu  bordar  and  print  haadlng 
CLEAR 

9  2,  0  TO  18,79  DOUBLE 

9  3,21  SAY  [PRINT  OPINION  RESULTS] 
9  4,1  TO  4,78  DOUBLE 

*  - display  detail  lines 

9  7,29  SAY  (1.  ACCESS  TO  CARE  REPORTS] 

9  8,29  SAY  (2.  NAITXNO  TIME  REPORTS] 

9  9,29  SAY  [3.  BATlSrACTION  REPORTS] 

9  10,29  SAY  [4.  DOCTOR  REPORTS] 

9  11,29  SAY  (h.  PATIENT  COIMENTS] 

9  13,  29  BAY  '0.  EXIT' 

STORE  0  TO  salaotnwt 
9  15,33  SAY  "  select 

9  15,42  OET  salactn'BS  PICTURE  "9"  RANGE  0,5 
PEAT 

DO  CASE 

CASE  salactnum  ■  0 
RETURN 

CASE  salactnum  •  1 
*  DO  ACCESS  TO  CARE  REPORTS 

DO  SKENU2_1 

SET  cc4iriRM  orr 

STORE  '  '  TO  walt_9Ub»t 

9  23,0  MY  ’ Press  any  kay  to  continue...'  GET 
walt___subst 

READ 
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SET  CONrXKM  ON 

CASE  ••l«etnum  •  2 

*  WMT^fin  TTM*  Af.POATS 

DO  aaN02_2 

SET  codriEM  orr 
STORE  *  '  TO  walt_«ubst 

I  23,0  SAY  'Pr««t  any  kay  to  contlnua...'  GET 
walt_aub«t 

READ 

SET  COHTIRM  ON 

CASE  ••lactnum  •  3 

*  DO  SATISrACTlQH  REPORTS 

DO  SHEN02_3 

SET  COHTIRM  OPP 
STORE  '  '  TO  aalt_aubat 

f  23,0  SAY  'Praaa  any  kay  to  contlnua...'  GET 
walt__8Ubst 

READ 

SET  COHPIRM  ON 

CASE  aalaetnum  •  4 

*  DO  DOCTOR  REPORTS 


CLEAR 
M_YR»0 
M  M0«0 

t?,  0  TO  9,7S  DOtTBLE 

•7, IS  SAY  "Entar  tha  Yaar  for  raport:”; 

GET  M_YR  PICTORE  "99" 

READ 

88,15  SAY  "Entaz  tha  Month  for  raport:"; 

GET  M_MO  PZCTORE  ”99"  RANGE  1,12 
READ 

•a*a*  fffiat  Doctor  Satlafaetioa  taSieator  Raport 

hara 


SET  COMPXRM  OPP 

STORE  '  '  TO  wait_sub»t 

8  23,0  SAY  'Praa«*~any  kay  to  continua...'  GET 
wait^aubat 

READ 

SET  CONFIRM  ON 

CASE  aalaetnum  ■  S 
*  DO  PATIENT  COItaNTS 
CLEAR 
M_MO  -  0 
M  YR  ■  0 

8«, 0  TO  9,79  DOOBLE 

87.15  SAY  "Entar  tha  Yaar:"; 

GET  M_YB  PICTURE  "99" 

READ 

88.15  SAY  "Entar  tha  Month  for  tha  daalrad 

connanta  s 

GET  M_M0  PICTURE  "99"  RANGE  1,12 

READ 

CLEAR 

REPORT  FORM  PATCOfM  FOR  YEAR«M_YR  .AND.  f40NTB«M__M0 
.AND.  PATCCPt4ENTS  -  "Y" 

822,0 

WAIT 

ENDCASE 

ENDDO  T 
RETURN 

*  EOF  I  SMENU2.PRG 


«  - Dlaplay  manu  optlona,  eantarad  on  tha  aeraan. 

*  draw  manu  bordar  and  print  haadlng 
CLEAR 

82,  0  TO  12,79  DOUBLE 

8  * ,  1  *»  f^AY  iri'-VEilf*  TO  CARE  REP'^PTr: 

8  4, X  TO  4,78  DOUBLE 

*  - dlaplay  datall  linaa 

8  7,32  SAY  [1.  DEPARTiaNT  REPORT] 

8  6,32  SAY  [2.  CLINIC  REPORT] 

8  10.  32  SAY  '0.  EXIT' 

STORE  0  TO  aalaetnum 
8  12,33  SAY  ”  aalaet 

8  12,42  GET  aalaetnum  PICTURE  ”9"  RANGE  0,2 
READ 

DO  CASE 

CASE  aalaetnum  •  0 
RETURN 

CASS  aalaetnum  •  1 
*  DO  DEPARTMENT  REPORTS 


CLEAR 

M_YR»0 

M_MO-0 

86,0  TO  9,79  DOUBLE 

87.15  SAY  "Entar  tha  Yaar  for  raport:"; 
GET  M_YR  PICTURE  "99" 

READ 

88.15  SAY  "Entar  tha  Month  for  raport:”; 
GET  M_HO  PICTURE  ”99"  RANGE  1,12 

READ 


Print  Dapt.  Aeeasa  ta  Cara  Raport  bara 


SET  CONFIRM  OFF 
STORE  '  '  TO  aait_aubat 

8  23,0  SAY  'Praaa  any  kay  to  eontinua...'  GET 
walt_8ubat 

READ 

SET  CONFIRM  ON 

CASE  aalaetnum  •  2 
•  DO  CLINIC  REPORTS 

CLEAR 
M  YR«0 
M~MO»0 

86,0  TO  9,79  DOUBLE 

87.15  SAY  "Entar  tha  Yaar  for  raport:"; 

GET  M  YR  PICTURE  "99" 

READ 

86.15  SAY  "Entar  tha  Month  for  raportt"; 

GET  M_M0  PICTURE  "99"  RANGE  1,12 

READ 

CLEAR 

M_CLINIC  -  " 

#6,  0  TO  8,  79  DOUBLE 

87.15  SAY  "Entar  tha  Clinic  aaction  coda  for 

raport:"; 

GET  M_CLINIC  PICTURE  "8* AAA" 

READ 

*****  Print  CXinle  Aceaaa  to  eara  raport  hara  * 


SET  CONFIRM  OFF 

STORE  '  '  TO  a«lt_aubat 

8  r?,0  SAY  'Praaa  any  kay  to  eontinua...'  GET 
walt_aubat 

READ 

SET  CONFIRM  ON 

ENDCASE 


*  Program. . 

ammn  x  .prg 


ENDDO  T 
RETURN 

*  EOF:  SMENU2  l.PRG 

*2 


*  Author . . . t 

*  Data . 

*  Notlca . . . ! 

*  Notaa. . . . : 


JOAN  £I»«4BRMAN  ft  ELBERT  SHAN 
02/19/89 

Copyright  <c)  1989  All  Rigbta  Raaarvad 
Aceaaa  to  Cara  Raporta 


SET  TALK  OFF 
SET  BELL  OFF 
SIT  STATUS  OFF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 


DO  NIXLE  .T. 


*  ProGzam. . : 

■lONUS  2. PRO 


*  Author. . . 

•  Data . 

*  Notlca, . . ; 

•  Notaa . . . . : 


JOAN  SZM4EFHAN  ft  ELBERT  SHAN 
02/19/89 

Copyright  (c)  1989,  All  Rights  Raaarvad 
malting  Tina  Raporta 


SET  TALK  OFF 
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SIT  Bcu.  orr 

SIT  STATOS  Off 
SIT  iscAFi  orr 

SIT  COWFIMi 
DO  1IBXZ.1  .T. 

*  —Display  manu  options,  eantsrsd  on  ths  scraan. 

*  draw  »anu  bordar  and  print  baadlng 
CLIAA 

i  2,  0  TO  12,79  DOUBLE 

t  3,21  SAY  (WAITINO  TIME  REPORTS) 

•  4,1  TO  4,78  DOUBLE 

*  — Replay  datail  linas 

f  7,32  SAY  [1.  DEPARTMENT  REPORT) 
t  8,32  SAY  [2.  CLINIC  RIPORT] 

I  10,  32  SAY  '0.  EXIT' 

STORl  0  TO  salaetnum 

•  12,33  SAY  "  salact 

•  12,42  OIT  salactnun  PICTURE  **9"  RANGE  0,2 
RIAD 

DO  CASE 

CASB  salaetnuB  •  0 
RITURM 

CASI  salaetnum  •  1 
*  DO  DEPARTMENT  RIPORTS 


CLEAR 

M_yR-0 

M_MO-0 

96,0  TO  9,79  DOUBLE 

97.15  SAY  "Entar  tha  Yaar  for  raportt"; 

OIT  M_YR  PICTURE  "99" 

RIAD 

96. 15  SAY  "Intar  tha  Month  for  raport:"; 

GST  M_M0  PICTURE  "99"  RANGE  1,12 

RIAD 

*****  Priat  Dapt.  Naitia^  TIjm  Raport  hara  ***** 

SET  CONTIRH  OFF 
STORl  '  '  TO  wait_subst 

9  23,0  SAY  'Prass  any  kay  to  contlnua...'  GET 
wait  subst 

RIAD 

SIT  CONTI RM  ON 


«  Author...:  JOAN  ZXW4BRMAN  <  ELBERT  SIAN 

*  Data . j  02.19/®? 

*  HoMes...:  Copyrlqh*-  (e»  1*8®,  111  Rlahts  Pssarvad 

*  Not  os .  .  .  .  t  Bat  iff  ( 1  oti  Pop'  I  *  ^ 

SIT  TALK  orr 
SET  BILL  orr 
SIT  STATUS  Off 
SET  ESCAPE  OFF 
SIT  CONTIRH  OH 

DO  NBILE  .T. 

*  -—Display  aanu  options,  eantarad  on  tha  scraan. 

*  draw  aanu  bordar  and  print  haadinG 
CLEAR 

9  2,  0  TO  12,79  DOUBLE 

9  3,21  SAY  [SATISrACTlON  REPORTS] 
9  4,1  TO  4,78  DOUBLE 

*  — '-display  datail  linas 

9  7,32  BAY  [1.  DIPARTHINT  RIPORT] 

9  6,32  SAY  12.  CLINIC  RIPORT) 

9  10,  32  SAY  '0.  EXIT' 

STORE  0  TO  salaetnum 
9  12,33  SAY  "  salact 

9  12,42  GIT  salaetnum  PICTURE  "9"  RANGE  0,2 
RIAD 

DO  CASK 

CASE  salaetnum  ■  0 
RSTURN 

CASK  salaetnum  •  1 
*  DO  DEPARTMENT  REPORTS 

CLEAR 

M_YR»0 

M_MO-0 

96,0  TO  9,79  DOUBLE 

97.15  SAY  "Entar  tha  Yaar  for  raport:"; 

GET  M_YR  PICTURE  "99" 

READ 

98.15  SAY  "Entar  tha  Month  for  raport:"; 

GET  M  HO  PICTURE  "99"  RANGE  1,12 

RIAD 

*•••*  friat  Dapt.  aatiafaatiea  Raport  kara  ***• 


CASB  salaetnum  •  2 
•  DO  CLINIC  RIPORTS 

CLEAR 
M  YR-0 

m”mo-o 

96,0  TO  9,79  DOUBLE 

9'?,  15  SAY  "Intar  tha  Yaar  for  raport:"; 

GET  M  YR  PICTURE  "99" 

RIAD  ” 

98.15  SAY  "Entar  tha  Month  for  report:"; 

GET  M_MO  PICTURE  "99"  RANGE  1,12 

RIAD 

CLEAR 

M^CLINIC  -  " 

96,0  TO  8,79  DOUBLE 

97.15  SAY  "Entar  tha  Clinic  section  coda  for 

report : 

GET  H_CL1NIC  PICTURE  "91AA9" 

RIAD 

*****  Print  Clinic  WaitinG  Tima  Raport  hara  ***** 


SIT  CONFIRM  orr 
STORl  '  '  TO  walt^subst 

9  23,0  SAY  'Press  any  key  to  continue. GET 
wait^subst 

READ 

SET  CONFIRM  ON 

IHDCASS 

BNDDO  T 
RITURN 

*  EOF:  SMENU2_2.PRO 


SIT  CONFIRM  orr 
STORE  '  '  TO  ualt^subst 

9  23,0  SAY  'Prass^ny  key  to  continue...'  GET 
walt^subst 

~  RIAD 

SET  CONFIRM  ON 

CASE  salaetnum  ■  2 
•  DO  CLINIC  REPORTS 

CLEAR 
M_YR-0 
M  MO-0 

96,0  TO  9,79  DOUBLE 

97.15  SAY  "Enter  tha  Yaar  for  report:"; 

GET  M_YR  PICTURE  "99" 

READ 

98.15  SAY  "Entar  tha  Month  for  report:"; 

GET  M_MO  PICTURE  "99"  RANGE  1,12 

riAi> 

CLEAR 

M_CLINIC  -  •  " 

96,0  TO  8,79  DOUBLE 

97.15  SAY  "Inter  tha  Clinic  section  coda  for 

raport : " ; 

GET  H__CL2NIC  PICTURE  "9! AAA" 

RIAD 

*****  Print  Clinic  satiafactiea  report  hara  ***** 

SIT  CONFIRM  orr 
STORE  '  '  TO  walt_subst 

9  23,0  SAY  'Press  any  key  to  continue...'  GET 
walt^subsl 

RIAD 

SET  CONFIRM  ON 

ENDCASE 


*  ProGram. . : 

mmmn  s.pro 


EHDDO  T 
RETURN 

•  EOF:  8MENU2_3.PRO 
"E 
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APPENDIX  G.  PRODUCTIVITY  PROGRAMS 


TABU  or  fROGRAME 

VMIMU.PRG 
VMBNUl . PRO 
VMEMDi_l .  PRO 
VMBMU2.PRO 
VMBNUS.PRO 


DZSCLAZmA 

rhr  purpose  of  this  programing  coda  is  to 
facilitate  the  understanding  of  the 
requirements  presented  in  Chapter  5  of  this 
thesis.  The  nature  of  this  project  precludes 
It  actual  inplementation  in  DBASE  IIJ+.  To 
fully  inplement  the  requirements  the  system 
designer  will  need  a  full  range  of  capabilities 
that  does  not  currently  exist  in  DBASE  IlJ-f. 

DBASE  III*  served  as  the  modeling  tool  by 
which  the  screens  were  generated  and  where 
necessary,  specific  code  was  written  to 
illustrate  a  point.  The  actual  working  code 
merely  acts  as  a  shell  in  which  to  run  the 
menus.  A  close  analysis  of  the  program  code  can 
facilitate  implementation  in  a  more  suitable 
language,  i.e.,  PARADOX,  which  can  support  the 
graphics  and  high  level  relationships  involved 
in  the  various  databases .  Where  the  actual 
requirements  process  may  appear  to  be  u/iciear^ 
comments  were  added  within  the  code  to  explain 
these  areas  to  the  designer . 


DO  VMINUl 

SET  CONFIRM  OFF 
STORE  '  '  TO  WRlt_*ub»t 

I  23,0  SAY  'Pr*««  any  k*y  to  eontlnu*...'  GET 
w«lt_«ubat 

READ 

SET  CONFIRM  ON 

CASE  ■•loctnum  -  2 

*  DO  DEPT  C  CLINIC  PRODUCTIVITY 

DO  VMENU2 

SET  CONFIRM  OFF 
STORE  '  '  TO  valt^Rubat 

I  23,0  SAY  'Pr**f  mny  kmy  to  continu*...'  GET 
READ 

SET  CONFIRM  ON 
CASE  ••Iftctnun  •  3 

*  DO  EXPBNDXTURE/VISIT  COMPARISON 

DO  VMENU3 

SET  CONFIRM  OFF 
STORE  '  '  TO 

6  23,0  SAY  *Pr»*a  any  k*y  to  contlnua...'  GET 
«f«lt_tubat 

READ 

SET  CONFIRM  ON 

ENDCA5E 

ENDDO  T 
RETURN 

*  EOFt  VMENU.PRG 


*  Progran. . 

VMKNU.PRO 

*  Author...:  JOAN  ZXM4ERMAN/ELBCRT  SHAN 

«  Dat* . :  02/23/89 

*  Notlca...:  Copyright  (c)  1989,  All  Rights  R«s«rv«d 
SET  TALF  OFF 

SET  SELL  OFF 
SET  STATUS  OFF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 

DO  WHILE  .T. 

«  ---Display  nanu  options,  cantarad  on  tha  scraan. 

*  draw  nanu  Dordar  and  print  haadlng 
CLEAR 

t  2,  0  TO  13,79  DOUBLE 

I  3,13  SAY  [DEPARTMENT  OF  FAMILY  PRACTICE  PRODUCTIVITY 
SYSTEM) 

$  4,1  TO  4,78  DOUBLE 

•  - display  datall  llnas 

9  7,25  SAY  [1.  UPDATE  VISIT  FILE] 

9  8,25  SAY  [2.  DEPT  «  CLINIC  PRODUCTIVITY] 

9  9,  25  SAY  [3.  EXPENDITURE ''VISIT  CCMPAPISON] 

9  11,  25  SAY  '0.  EXIT' 

STORE  0  TO  salaetnun 
9  13,33  HAY  "  salaet 

9  13,42  GET  salaetnun  PICTURE  "9”  RANGE  0,3 

READ 

DO  CASE 

CASE  salaetnun  •  0 
SET  BELL  ON 
SET  TALK  ON 
CLEAR  ALL 
RETURN 

CASE  salaetnun  -  1 
*  DO  UPDATE  VISIT  FILE 


*  Progran. 

vmui.fRe 

*  Author...:  JOAN  EIieaRHAN/ELBERT  SHAW 

*  Data . :  02/23/89 

*  Notlca...:  Copyright  (c)  1989,  All  Rights  Rasarvad 

*  Notas. . . . i 
SET  TALK  OFF 
SET  BELL  OFF 
SET  STATUS  OFF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 

DO  WHILE  .T. 

•  - Dlr-play  nanu  options,  cantarad  on  tha  scraan. 

*  draw  nanu  bordar  and  print  baadlng 
CLEAR 

92,  0  TO  12,79  DOUBLE 

9  3,24  SAY  [UPDATE  VISIT  FILE] 

9  4,1  TO  4,78  DOUBLE 
«  ---display  datall  llnas 
9  7,21  SAY  [1.  UPDATE  VISIT  DATA*] 

9  6,21  SAY  [2.  EXTRACT  VISIT  DATA  FRCM  HED302  FILE] 

9  10,  21  SAY  '0.  EXIT' 

STORE  0  TO  salaetnun 
9  12,33  SAY  *•  ralact 

9  12,4:  rrr  aal«r*nun  PI'“T^Pf  "9"  RAN'7B  0,2 
9  16,15  SAY  "*  TM ‘.ption  allows  you  to  antar  visit 
9  17,15  SAY  *  data  fron  tha  kayboard." 

READ 
DO  CASE 

CASE  salaetnun  •  0 
RETURN 

CASE  aalactnun  1 
•  DO  ENTBP  VISIT  DATA 

DO  VMENUl^l 

SET  CONFIRM  OFF 

STORE  '  '  TO  wait_subst 

9  23,0  SAY  'Prass  any  kay  to  continua...'  GET 
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walt_*ub«t 

READ 

SET  CONFIRM  ON 
CASE  ••l«etnuiB  ■  2 

*  DO  EXTRACT  VISIT  DATA  FROM  MED302  FILE 


*****  Mctraet  Tlslt  froM  — dSOE 

fU.«  ***** 

SET  CCWIRM  OFF 

STORE  '  '  TO  walt_subst 

9  23,0  SAY  'Fr«sa  any  k*y  to  eontinu*...'  SET 
walt_subat 

READ 

SET  CONFIRM  ON 

EMDCASE 

ENDOO  T 
RETORN 

*  EOF:  VMEMOl.PRO 
*E 


*  Pro^rm..! 

VMIRXX^l  .PRO 

*  Author...t  JOAN  22>#fERHAN/ELfiERT  SHAN 

*  Data . !  02/23/89 

*  Motlca...:  Copyright  (c)  1989  All  Rights  Rasarvad 
SET  TALK  OFF 

SET  BELL  OFF 
SET  STATUS  OFF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 
USE  VISIT 

DO  WHILE  .T. 

*  --^Display  nahu  options,  cantarad  on  tha  seraan. 

*  draw  Bkanu  bordar  and  print  haadlng 
CLEAR 

9  2,  0  TO  14,79  DOUBLE 

9  3,24  SAY  (UPDATE  VISIT  DATA) 

9  4,1  TO  4,78  DOUBLE 

*  —display  datail  linas 

9  7,30  SAY  (1.  ADD  VISIT  DATA) 

9  9,30  SAY  (2.  CHANGE  VISIT  DATA] 

9  9,30  SAY  (3.  REMOVE  VISIT  DATA] 

9  10,30  SAY  (4.  REVIEW  VISIT  DATA] 

9  12,  30  SAY  '0.  EXIT' 

STORE  0  TO  salaetnun 
9  14,33  SAY  **  salaet 

9  14,42  GET  salaetnun  PICTURE  "S'*  RANGE  0,4 

READ 

DO  CASE 

CASE  salaetnun  •  0 
RETURN 

CASE  salaetnun  *  1 

*  DO  ADD  INFORMATION 

SET  FORMAT  TO  VISIT 
APPEND 

SET  FORMAT  TO 

SET  CONFIRM  OFF 

STORE  '  '  TO  wait_subst 

9  23,0  SAY  'Prass  any  kay  to  contlnua...'  GET 
walt_^subst 

“  READ 

SET  CONFIRM  ON 

CASE  salaetnun  ■  2 

*  DO  CHANGE  INFORMATION 

SET  FORMAT  TO  VISIT 
EDIT 

SET  FORMAT  TO 

SET  CONFIRM  OFF 

STORE  '  '  TO  walt^subst 

9  23,0  SAY  'Prass  any  kay  to  contlnua...'  GET 
walt^subst 

READ 

SET  CONFIRM  ON 

CASE  salaetnun  ■  3 

*  DO  REMOVE  INFORMATION 

SET  TALK  ON 


CLEAR 

9  2,0  SAY  '  ' 

7  'PACKING  DATABASE  TO  REMOVE  RECORDS  MARKED  FOR 
DELETION' 

'lACK 

SET  TALK  OFF 

SET  CONFIRM  OFF 

STORE  '  '  TO  walt_subst 

9  23,0  SAY  'Prass  any  kay  to  contlnua...'  GET 
Nait_subst 

READ 

SET  CONFIRM  CH4 

CASE  salaetnun  >  4 
*  DO  REVIEW  INFORMATION 

BROWSE  HOMENU  NOAPPEND 
SET  CONFIRM  OFF 
STORE  '  '  TO  walt_subst 

9  23,0  SAY  'Prass  any  kay  to  eontlnua...'  GET 
walt__^subst 

READ 

SET  CONFIRM  ON 

ENDCASE 

ENDDO  T 
RETURN 

*  EOF:  VMEMU1_1.PR6 
''2‘^Z 


*  Progran. . : 

VWNDE.PBO 

*  Author...:  JOAN  ZIM4XRMAN/ELBERT  SRAW 

*  Data . :  02/23/89 

*  Notlca...:  Copyright  (o)  1989  All  Rights  Rasarvad 
SET  TALK  OFF 

SET  BELL  OFF 
SET  STATUS  OFF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 

DO  WHILE  .T. 

*  —Display  nanu  options,  eantarad  on  tha  seraan. 

*  draw  nanu  bordar  and  print  haadlng 
CLEAR 

92,  0  TO  12,79  DOUBLE 

9  3,13  SAY  [DEPT  ft  CLINIC  PRODUCTIV 
I  T  YJ 

9  4,1  TO  4,78  noUBLE 

*  -—display  datail  linas 

9  7,26  SAY  (1.  TOTAL  MONTH  VISITS] 

9  8,26  SAY  [2.  CLINIC  ft  DEPT  VISIT  TRENDS] 

9  10,  26  SAY  '0.  EXIT' 

STORE  0  TO  salaetnun 
9  12,33  SAY  "  salaet  " 

9  12,42  GET  salaetnun  PICTURE  "9*  RANGE  0,2 
READ 

DO  CASE 

CASE  salaetnun  ■  0 
RETURN 

CASE  salaetnun  •  1 

*  DO  TOTAL  MONTH  VISITS 

CLEAR 

M[_MO«0 

M_YR«0 

96,0  TO  9,79  DOUBLE 

97.15  SAY  "Bntar  tha  yaar  for  raport"; 

GET  M_YR  PICTURE  "99" 

READ 

99.15  SAY  "Entar  tha  nonth  for  raport"; 

GET  fl  no  norOPE  ■’99" 

PEAT 

•••••  TOTAL  MOimis  VXBXT  BAR  GRAPH  BRH  ***** 

SET  CONFIRM  OFF 
STORE  '  '  TO  walt^subst 

9  23,0  SAY  'Prass  any  kay  to  contlnua...'  GET 
wait  subst 

~  READ 

SET  CONFIRM  ON 

CASE  salaetnun  •*  2 

*  DO  CLINIC  ft  DEPT  VISIT  TRENDS 

CLEAR 
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M_H0-0 

#6,0  TO  $,79  DOUBLE 

f7,l5  SAY  "Int#r  th«  y»ar  for  raport."; 

ORT  t!_vr  FT  'T'’rr 

BEAD 

*****  CLIMZC  «  DIPT  VXBZT  TMUO  CMPR  RBAB  •**< 

SET  coNriBM  orr 

•TORI  '  '  TO  w*lt_»ub*t 

I  23,0  SAY  'Pra**  any  Eay  to  eontlnua...*  qet 
wait_sub*t 

READ 

SET  CMiriRM  ON 

EMDCASE 


STORE  '  '  TO  walt_aubst 
0  23,0  SAY  'Praaa  any  kay  to  continua 
walt_aubat 

READ 

SET  cowrrpii  on 

ENDCASE 

ENDDO  T 
RETURN 

*  EOr:  VMENUl.pRO 

*'1 


ENDDO  T 
RETURN 

•  sort  VHBNU2.PR<3 


*  Program. . > 

VmU3.»M 

*  Author...}  JOAN  SIMKERMAN/ELBERT  SEAM 

*  Data . }  02/23/89 

*  Notlca...:  Copyright  <c)  1989,  All  Righta  Raaarvad 
SET  TALK  orr 

SET  BELL  orr 
SET  STATUS  orr 
SET  ESCAPE  orr 
SET  CONFIRM  ON 

DO  NRILE  .T. 

«  - Display  Manu  optlona,  cantarad  on  tha  acraan. 

*  draw  manu  bordar  and  print  kaadlng 
CLEAR 

*  2,  0  TO  12,79  DOUBLE 

03,l3SAytEXPENDlTORE/VrSlT  COMPA 
R  X  S  0  N] 

6  4,1  TO  4, 78  DOUBLE 

*  •-•display  datall  Unas 

t  7,28  SAY  [J.  CL:SIC  tXPtHDITOM  ft*  VISIT  RIPOPT) 
t  8,28  SAY  (2.  OifT.  fXPtSDITOM  VS  VISIT  TRIM)  RtfOFT] 

'  t  10,  28  SAY  '0.  tXIT' 

STORE  0  TO  salaetnun 
«  12,33  SAY  "  salact 

0  12,42  OET  salaetnun  PICTURE  "9"  RANGE  0,2 

READ 

DO  CASE 

CASE  salaetnun  •  0 
RETURN 

CASE  salaetnun  •  1 
*  DO  CLINIC  EXPEND.  PER  VISIT 

CLEAR 

M_MO-0 

M__YB-0 

06,0  TO  9,79  DOUBLE 

07,15  SAY  "Entat  tha  yaar  for  raport"; 

GET  M_YR  PICTURE  "99” 

READ 

08,15  SAY  "Entar  tha  month  for  raport"; 

GET  M_MO  PICTURE  "99" 

READ 

••««*  Print  Clinic  nenths  mi^/Tisit  raport  hara 


SET  cc»9riRM  orr 
STORE  '  '  TO  walt^aubst 

0  23,0  SAY  'Praaa  any  hay  to  continua...'  GIT 
wolt_aubst 

READ 

SET  CONFIRM  ON 

CASE  salaetnun  •  2 
*  DO  EXPEND.  VS  VISIT  TREND 
CLEAR 
M_YR»0 

06,0  TO  8, 79  DOUBLE 

07,15  SAY  "Entar  tha  yaar  for  raport"; 

GET  M_YF  PICTURE  "99" 

READ 


)•***  Print  Dapt  BXP  VS  VISIT  TRJDID  REPORT  BBSS 

SET  CONTIRM  OFF 


'  QET 


247 


LIST  OF  REFERENCES 


Aktas,  A.Z.,  Structured  Analysis  &  Design  of  Information  Systems,  Prentice-Hall,  Inc., 
1987. 

Boar,  B.H.,  Application  Prototyping,  A  Requirements  Definition  Strategy  for  the  80s, 
John  Wiley  &  Sons,  1984. 

Burnett,  N.,  "Human  Perception  and  Good  User  Interface  Design,"  Chips,  pp.  29-30, 
October  1988. 

Ceri,  S.,  "Requirements  Collection  and  Analysis  in  Information  Systems  Design,” 
AFIPS,  Proceedings  of  the  National  Computer  Conference,  pp.  205-212,  AFIPS  Press, 
1982. 

Cerveny,  R.P.,  and  others,  "Why  Software  Prototyping  Works,"  Datamation,  pp.  97- 
103,  15  August  1987. 

Cowey,  H.D.,  and  McAlister,  N.H.,  Computers  in  the  Practice  of  Medicine,  v.  2, 
Addison-Wesley  Publishing  Company,  1980. 

Department  of  Defense,  Assistant  Secretary  of  Defense  (Health  Affairs),  DOD 
6010.13-M,  Medical  Expense  Reporting  and  Performance  Reporting  System  for  Fixed 
Military  Medical  and  Dental  Treatment  Facilities,  1986. 

Department  of  the  Army,  Health  Services  Conunand,  HSC  Regulation  10-1,  Government 
Printing  Office,  Washington,  DC,  1987. 

Duffe,  E.G.,  "The  Patient  Satisfaction  Questionnaire,"  College  Review,  pp.  39-64,  1985, 
cited  in  Landry,  K.E.,  "Developing  and  Testing  an  Inpatient  Satisfaction  Questionnaire 
for  Use  in  Naval  Hospitals,"  p.  17,  Master’s  Thesis,  Baylor  University,  1987. 

Ertel,  P.Y.,  "Accuracy  in  the  Reporting  of  Clinical  Data:  Proper  Roles  for  the  Physician 
and  the  Computer,"  Proceedings  -  Symposium  on  Computer  Applications  in  Medical 
Care,  pp.  484-486,  IEEE  Computer  Society,  1984. 

Galitz.  W..  "Human  Engineering  in  Screen  Design,"  Journal  of  Systems  Management, 
pp.  6-11,  May  1983. 

Harrison,  R.,  "Prototyping  and  the  System  Development  Life  Cycle,"  Journal  of  Systems 
Management,  v.  36,  pp.  8,  22-25,  Association  for  Systems  Management,  1985. 


248 


Ives,  B.,  "Graphical  User  Interfaces  for  Business  Information  Systems,"  MIS  Quarterly 
(Special  Issue),  pp.  15-47,  December  1982. 

Kq>lan,  B.,  "Barriers  to  Medical  Computing:  History,  Diagnosis,  and  Therapy  for  the 
Medical  Computing  Lag,"  Computer  /^plications  in  Medical  Care,  pp.  400-403,  IEEE 
Computer  Society  Press,  1985. 

Kendall,  K.E.,  and  Kendall,  J.E.,  Systems  Analysis  and  Design,  Prentice- Hall,  Inc., 
1988. 

Knittle,  D.L.,  Knittle,  R.S.,  and  Gardner,  E.P.,  "Establishing  User  Centered  Criteria  for 
Information  Systems:  A  Software  Ergonomics  Perspective,"  Information  and 
Management,  v.  11,  pp.  163-172,  1987. 

Kroenke,  D.M.,  and  Dolan,  K.A.,  Business  Computer  Systems,  An  Introduction,  3d  ed., 
Mitchell  Publishing,  Inc.,  1987. 

Landry,  K.E.,  Developing  and  Testing  an  Inpatient  Satisfaction  Questionnaire  for  Use 
in  Naval  Hospitals,  Master’s  Thesis,  Baylor  University,  1987. 

Libra  Technology,  User’s  Manual  for  the  COSTAR  System  at  Silas  B.  Hay^s  Army 
Community  Hospital,  rev.  2,  1982. 

Lockeman,  P.C.,  and  Mayr,  H.C.,  "Information  System  Design:  Techniques  and 
Software  Support,"  Proceedings  of  the  lOth  World  Computer  Conference,  pp.  617-634, 
Elsevier  Science  Publishers  B.V.,  1986. 

Longest,  B.B.  Jr.,  "Relationships  Between  Coordination,  Efficiency,  and  Quality  of  Care 
in  General  Hospitals,"  Relationships  Between  Coordination,  Efficiency,  and  Quality  of 
Care  in  General  Hospitals,  pp.  123-142,  Health  Administration  Press,  1978. 

Lyons,  J.P.,  Karwan,  M.H.,  and  Kostusiak,  J.,  "An  Interactive  Provider  Scheduling 
Program  for  HMO’s  and  Larger  Group  Practices,"  Computer  Applications  in  Medical 
Care,  pp.  435-439,  IEEE  Computer  Society  Press,  1985. 

Martin,  C.F.,  User-Centered  Requirements  Analysis,  Prentice-Hall,  Inc.,  1988. 

Martin,  J.,  Strategic  Data-Planning  Methodologies,  Prentice-Hall,  Inc.,  1982. 

Martin.  M.P.,  and  Fuerst,  W.L..  "Using  Computer  Knowledge  in  the  Design  of 
Interactive  Systems,"  International  Jourml  of  Man-Machine  Studies,  v.  26,  no.  3,  pp. 
333-392,  March  1987. 


249 


Office  of  the  Assistant  Secretary  of  Defense,  Health  Affairs,  Defense  Medical  Systems 
Support  Center,  Regional  Training  Conference  Manual,  January  1988. 

Pelletier,  M,,  "Client  Satisfaction  Surveys:  Variables  to  Watch  Out  For,"  Dimensions,  , 

pp.  37-39,  1985,  cited  in  Landry,  K.E.,  "Developing  and  Testing  an  Inpatient 
Satisfaction  Questionnaire  for  Use  in  Naval  Hospitals,"  p.  2,  Master’s  Thesis,  Baylor 
University,  1987. 

9 

Rakich,  J.S.,  and  Darr,  K.,  Hospital  Organization  and  Management:  Text  and  Readings, 

2d  ed.,  SP  Medical  and  Scientific  Books,  1978. 

Sadock,  R.T.,  "A  Clinical  Information  System  for  Yale-New  Haven  Hospital,"  Resident 
and  Staff  Physician,  pp.  114-119,  February  1986. 

Satir,  A.,  "Statement  Before  the  Subcommittee  on  Domestic  and  International  Scientific 
Planning,  Analysis  and  Cooperation,  United  States  House  of  Representatives,” 

Computers  in  Health  Care,  pp.  97-103,  U.S.  Goverrunent  Printing  Office,  1978. 

Scharer,  L.,  "The  Prototyping  Alternative,"  /7T  Programming,  v.  1,  pp.  34-43,  1983. 

Senn,  J.A.,  Information  Systems  in  Management,  3d  ed.,  Wadsworth  Publishing 
Company,  1987. 

Stahl,  B.,  "Friendly  Mainframe  Software  Guides  Users  Toward  Productivity," 
Computerworld,  v.  20,  no.  5,  pp,  53-66,  3  Febraary  1986.  ' 

Sumner,  M.,  and  Sitek,  J.,  "Are  Structured  Methods  for  Systems  Analysis  and  Design 

Being  Used?,"  Journal  of  Systems  Management,  v.  37,  pp.  18-23,  June  1986.  r 

Swan,  J.E.,  and  others,  "Deepening  the  Understanding  of  Hospital  Patient  Satisfaction: 

Fulfillment  and  Equity  Effects,"  Journal  of  Health  Care  Marketing,  pp.  7-16,  1985, 
cited  in  Landry,  K.E.,  "Developing  and  Testing  an  Inpatient  Satisfaction  Questionnaire 
for  Use  in  Naval  Hospitals,"  p.  5,  Master’s  Thesis,  Baylor  University,  1987. 

Vegoda,  P.R.  and  Dyro,  J.F.,  "Implementation  of  an  Advanced  Clinical  and 
Administrative  Hospital  Information  System,"  International  Journal  of  Clinical 
Monitoring  and  Computing,  pp.  259-268,  Martinus  Nijhoff  Publishers,  1986. 

Wasserman,  A.I.,  "Information  System  Design  Methodology,"  Tutorial  on  Software 
Design  Techniques,  pp.  43-60,  Computer  Society  Press,  1984. 

Whitten,  J.L.,  Bently,  L.D.,  and  Ho,  T.I.M.,  Systems  Analysis  and  Design  Methods, 

Time  Mirror/Mosby  College  Publishing,  1986.  * 


250 


Willis,  T  H.,  Huston,  C.R.,  and  d’Ouville,  E.L.,  "Project  Manager’s  Responsibilities  in 
a  Prototyping  Systems  Analysis  and  Design  Environment,"  Project  Management 
Journal,  pp.  56-60,  February  1988. 

Yourdon,  E.,  "What  Ever  Happened  to  Structured  Analysis,"  Datamation,  pp.  133-138, 
1  June  1986. 

Yourdon,  E.,  Managing  the  System  Life  Cycle,  2d  ed.,  Yourdon  Press,  1988. 


251 


INITIAL  DISTRIBUTION  LIST 


No.  Copies 

1.  Defense  Technical  Information  Center  2 

Cameron  Station 

Alexandria,  VA  22304-6145 

2.  Library,  Code  0142  2 

Naval  Postgraduate  School 

Monterey,  CA  93943-5002 

3.  Director,  Information  Systems  (OP-945)  1 

Office  of  the  Chief  of  Naval  Operations 

Navy  Department 
Washington,  DC  20350-2000 

4.  Commandant  of  the  Marine  Corps  2 

Code  TE  06 

Headquarters,  U.S.  Marine  Corps 
Washington,  DC  20360-0001 

5.  Superintendent,  Naval  Postgraduate  School  1 

Computer  Technology  Programs,  Code  37 

Monterey,  CA  93943-5000 

6.  Professor  Thomas  P.  Moore  2 

Department  of  Administrative  Sciences,  Code  54Mr 

Naval  Postgraduate  School 
Monterey,  CA  93943-5008 

7.  Commander,  Silas  B.  Hays  Army  Community  Hospital  2 

Information  Management  Division 

ATTN:  MAJ  Thomas  S.  Semarge 
Fort  Ord,  CA  93941-5800 

8.  Defense  Logistics  Studies  Information  Exchange  1 

U.S.  Army  Logistics  Management  College 

Fort  Lee,  VA  23801 

9.  Commanding  Officer  3 

Naval  Medical  Data  Services  Center 

National  Naval  Medical  Center 
Bethesda,  MD  20814 


252 


2 


10.  CPT(P)  Elbert  T.  Shaw,  Jr. 
c/o  Dr.  Greely  Moore 
356  Gaines  Avenue 
MobUe.  AL  36608 

11.  CAPT  Joan  P.  Zinunerman  2 

Marine  Corps  Finance  Center 

1500  E  95th  Street 
Kansas  City,  MO  64197-0001 

12.  Mr.  William  Pugh  1 

Department  Head,  Code  20 

Naval  Health  Research  Center 

P.O.  Box  8512 

San  Diego,  CA  92138-9174 

13.  Dr.  Eric  Gunderson  1 

Chief  Scientist 

Naval  Health  Research  Center 
San  Diego,  CA  92138-9174 

14.  Assistant  Professor  Barry  Frew  1 

Department  of  Administrative  Sciences,  Code  54Fw 

Naval  Postgraduate  School 
Monterey,  CA  93943-5008 

15.  LCDR  Robert  R,  Taylor  1 

U.S.  Navy 

Patrol  Squadron  17 

FPO  San  Francisco  96601-5910 


253 


